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An Overview of the Project Cycle 


by Kevin Forsberg and Hal Mooz 


Projects are formed to achieve defined ob- 
jectives, which almost always include a set of 
technical requirements to be achieved within 
budget and schedule constraints. The Project 
Cycle is a tool that defines the typical project 
activities and their logical progression from the 
beginning to end. Many projects encounter 
serious difficulty and often fail because the 
project team ignores the proper sequencing of 
activities and events in the project cycle, 
particularly the “front-end” activities. Studies, 
such as the Hearth Committee report (NASA) 
and the Packard Presidential Commission 
report (DoD), emphasize the importance of not 
ignoring, bypassing, or improperly sequencing 
essential project cycle events. To comply, project 
managers must completely understand their 
project’s cycle. 

Many functional managers attempt to define 
the project cycle from their perspective. These 
attempts result in the Budget Cycle, the Sys- 
tem Development Cycle, the Acquisition Cycle 
and many other focused views of the typical life 
of a project. Development of a comprehensive 
project cycle has been hampered by the inability 
of the many interest groups involved to achieve 
consensus. Moreover, engineers tend to be 
reluctant to create a typical project cycle in fear 
that it will reduce their freedom to be inno- 
vative during the engineering portion of the 
cycle. 

Under contract to the U.S. Government, we 
have studied and evolved a baseline project cycle 
useful for all projects requiring concept 
selection, design, development, and operations. 
While fundamentally similar to the NASA 
planning process that includes Phases A, B, and 
C/D, it provides markedly clearer terminology, 
and has been carried to a depth of detail not 
previously available. 


Project Cycle Definition 

The project cycle is an illustration of the typical 
and necessary project events sequenced from 
beginning to end. There are three aspects or 
layers to the project cycle, each containing its 
own set of events. These layers are the Budget, 
Business, and Technical aspects. 

The Budget aspect contains all events relative to 
securing the necessary funding required by the 
project. The Business aspect contains all the 
events relative to the overall programmatic 
management of the project, including the 
acquisition process and associated contract 
management. The Technical aspect contains all 
the technical events relative to determining and 
satisfying the technical requirements of the 
project, and validating that the project solution 
complies with the requirements. 

The interwoven events for these three aspects 
constitute the total cycle. Each event or product 
of an event is assigned to one of four interrelated 
categories: Budget, Activities, Products, and 

Control Gates. See Figure 1, Project Cycle 
(Partial View), which shows these four cat- 
egories of events and related products. 

The “budget events” define the required 
planning for and securing of project funding and 
are keyed to important U.S. Government fiscal 
milestones imposed by the Office of Manage- 
ment and Budget (OMB). 

The “activities” include all sorts of actions such 
as to study, analyze, evaluate, select, design, etc. 

The “products” consist of activity results such as 
specifications, drawings and manuals; internal 
hardware and software such as technical feasi- 
bility models; and the deliverable hardware, 
software and documentation. 
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The “control gates” are predetermined, formal 
status and decision checkpoints which must be 
satisfied, or else the project is not sufficiently 
prepared to move on to future events without in- 
creased risk. 

Project Cycle Periods and Phases 

The project cycle is usually divided into periods 
and then further subdivided into phases. Our 
typical cycle is divided into the Study Period, 
the Acquisition Period, and the Operations Peri- 
od. These periods depict the three major periods 
of a project that progresses from an identified 
user need, through concept determination, con- 
tractor participation for development, and ulti- 
mately to user operation. 

The “Study Period” consists of four phases. They 
are the User Requirements Definition Phase 
(commonly known in NASA as pre-Phase A), the 
Concept Definition Phase (commonly known as 
Phase A), the System Performance Definition 
Phase (commonly known as Phase B), and the 
Acquisition Planning Phase. 

The “Acquisition Period” consists of the Source 
Selection Phase and the System Development 
Phase (commonly known as Phases C/D). 

The “Operations Period” consists of the Deploy- 
ment Phase and the Operations and Mainten- 
ance Phase. It is sometimes called Phase E. 

The objective of the “User Requirements De- 
finition Phase” at the start of the Study Period is 
to determine exactly which of the user’s total 
requirements will be included and satisfied by 
the proposed project. Usually, user require- 
ments are more comprehensive than can be 
reasonably or economically incorporated into a 
single project. Considerable analysis, nego- 
tiation and decision making must occur to 
identify the project’s subset of the user’s 
requirements, which are then recorded in the 
project’s System Requirements Document and 
signed off by both the user and the project 
manager. In addition, executive approvals for 
the project and initial project funding are 
secured. The need to control requirements, of 
course, is understood. 


The prime objective of the “Concept Definition 
Phase” is to select the preferred concept from 
possible candidates, and then to develop the 
budgetary “should cost” estimate and the 
“should take” schedule, and then to identify and 
resolve any areas of high risk. The System 
Performance Specification and the Interface 
Specifications are developed during the System 
Performance Definition Phase so that the 
selected system can be competed for the 
marketplace. During the Acquisition Planning 
Phase the approach to the acquisition is 
developed and documented in the Acquisition 
Plan, and a credible, qualified bidder’s list is 
prepared. If the project can be performed totally 
internal to NASA, the justification for this 
approach will be determined in this phase. 

The objective of the “Source Selection Phase” is 
to select through fair and open competition the 
best value through the comprehensive, 
analytical evaluation of contractor proposals. 
The system concept is designed, produced, 
verified and delivered during the “System 
Development Phase.” The events of this phase 
ensure that the concept is in full com-pliance 
with all contractual requirements. 

The main objective of the “Deployment Phase” 
is to transfer the system from the contractor’s 
facility to the operational location, and then to 
establish full operational capability of the sys- 
tem. The system is operated and evaluated in 
terms of the success of the system in meeting the 
original project objectives during the “Oper- 
ations and Maintenance Phase.” 

The Technical Aspect of the Project Cycle 

The Technical Aspect of the Project Cycle can be 
viewed as a “V” formation within the project cy- 
cle (see Figure 2, Overview of Technical Aspect 
of the Project Cycle). While budget and business 
events can typically be compressed and acceler- 
ated, the technical events are the most signifi- 
cant force in the project cycle, and ultimately 
they drive the length and cost of the project. 

The beginning and the end of the cycle deals 
with the user’s requirements and the user’s sat- 
isfaction, respectively. These are the highest 
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Figure 2 - Overview of the Technical Aspect of the Project Cycle 


levels of the “V.” In the center of the cycle, at 
Critical Design Review (CDR), the events of the 
project are at the lowest level, dealing with 
hardware and software process details such as 
fastening, bonding, and coding. The left side of 
the “V,” descending from the highest point to 
the lowest point, is defined as Decomposition 
and Definition. The right side of the “V”, ascend- 
ing to the fully operational system, is called In- 
tegration and Verification. System engineering 
is responsible for the technical management of 
the entire “V.” 

Typically, the upper portion of both sides of the 
“V” is managed by the government, with con- 
tractor participation. The center level of the “V” 
is managed by the contractor’s systems engi- 
neers, with design engineering participation 
and government oversight. The lower portion of 
the “V” is managed by the contractor’s design 


engineers, with oversight by the contractor’s 
systems engineers. 

Only the core of the “V” is presented in Figure 2. 
The process illustrated here is similar to the 
traditional waterfall model of system 
decomposition and integration. However, this 
model provides improvement in the under- 
standing process. Detailed hardware, software 
and operational analysis is recommended at 
each step in the decomposition to assess solution 
feasibility and risk, and to provide necessary 
data to select between various options (see 
Figure 3). As the project progresses from one 
step in the “V” to the next, only the decisions on 
the core are put under configuration 
management. 

Off-core details are illustrated by the process of 
requirements flowing down to successively 
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lower levels, performing trade-off analyses to 
determine the best approach at each level (as 
depicted in Figure 3). This progressive and 
iterative process is repeated until the lowest lev- 
el decisions have been made with valid ratio- 
nale, all traceable to the original user require- 
ments. Management of the Decomposition and 
Definition process demands both requirements 
traceability and baseline configuration manage- 
ment. The management of Integration and Ver- 
ification requires compliance verification and 
full accountability of all specified requirements. 
Systems engineering is responsible for this man- 
agement. 

As the project proceeds through the “V,” it pro- 
gresses in time and maturity. The maturity is 
measured by the evolving technical baseline, 
which is progressively placed under formal con- 
figuration control by the government project 
manager. 

At the beginning of the “V,” the approved base- 
line is the user’s agreed upon requirements. At 
Full Scale Development (Phase C/D contract 
award), the approved baseline is the System 
Performance Specification. At PDR (Prelimi- 
nary Design Review), the approved baseline be- 
comes the approved “Design-to” specifications. 
At CDR (Critical Design Review), the approved 
baseline becomes the “Build-to” documentation. 
Baseline evolution and approval continues 
throughout the project cycle. 


Project management is the most complicated of 
all management processes. It encompasses 
detailed sets of interrelated activities that 
involve many different specialty disciplines. 
These include funding, contracting, systems 
engineering, design engineering, production, 
quality, procurement, systems acquisition, 
systems integration, systems verification, 
configuration control, subcontracting, and many 
others. The interactive complexity is so great 
that it is difficult for even the most experienced 
team to operate proactively and efficiently 
without drawing on a baseline project cycle as a 
reference starting point. 

While there are those who proclaim that a 
defined project cycle inhibits the creativity of 
project participants, just the opposite is realized. 
By having defined a typical cycle that is tailored 
to the project and then further expanded into the 
strategic network and project plan, the project 
team is not distracted by day-to-day project ac- 
tivities. A defined process releases contributors 
to concentrate on content, rather than process. 

A defined project cycle illustrates the generic 
budget, business and technical events required 
to be successful. The project cycle should be 
tailored to the type of project and is the skeleton 
around which the strategic and tactical 
approaches to the project can develop into a 
logical network. By having a defined process, 
the team is free to be innovative and, therefore, 
more successful. 
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Systems Engineering and Integration Management 
for Manned Spaceflight Programs 

by Owen Morris 


This paper is one in a series prepared for NASA 
under contract from the Jet Propulsion Labora- 
tory. Although the papers were commissioned by 
the NASA Alumni League, which also provided 
editorial services , the opinions expressed in the 
paper belong solely to the author. 

The development of systems engineering and 
program management in NASA manned space 
programs has grown in a largely uncoordinated 
manner over the last 30 years; however, the 
systems and practices that have been developed 
form a proven pattern for successfully inte- 
grating large technically complex programs 
executed in several geographical locations. This 
development has not been recorded in a 
comprehensive manner, and much of the reason- 
ing behind the decisions made is not obvious. 

Although there is no generally accepted 
definition of SE&I, for the purposes of this 
discussion systems engineering is defined as the 
interdisciplinary engineering that is necessary 
to achieve efficient definition and integration of 
program elements in a manner that meets the 
system-level requirements. Integration is 
defined as the activity necessary to develop and 
document the system’s technical characteristics, 
including interface control requirements, 
resource reporting and analysis, system verif- 
ication requirements and plans, and inte- 
gration of the system elements into the program 
operational scenario. 

This paper discusses the history of SE&I 
management of the overall program archi- 
tecture, organizational structure, and the 
relationship of SE&I to other program 
organizational elements. A brief discussion of 
the method of executing the SE&I process, a 
summary of some of the major lessons learned, 
and identification of things that have proven 
successful are included. 


History 

NASA, then the National Advisory Committee 
for Aeronautics (NACA), participation in the 
management of major aerospace programs 
began shortly after World War II with the 
advent of the X-series research aircraft. In these 
projects, essentially all of the technical 
responsibility was delegated to one of the NACA 
Centers. At this time, the Centers were 
primarily expert in the technical areas being 
explored (i.e., aerodynamics, stability, control, 
and structures) but did not have experts in the 
development of hardware. Accordingly, NACA 
entered into agreements with the Air Force or 
Navy to manage the actual development of the 
aircraft, while the NACA Centers focused their 
direction on the technical requirements and 
performance characteristics to be demonstrated 
by the aircraft. The contractor’s responsibility 
was similar to that for the development of any 
aircraft, and the contractor usually furnished 
test pilots for early demonstration flights. 

With the formation of NASA and the start of 
major manned space programs, it was necessary 
for NASA to develop the capability to manage 
complex development activities. Very little 
SE&I capability existed within the functional 
organizations of the NASA Centers. As a result, 
SE&I expertise was developed within each of the 
program offices. In particular, the Gemini pro- 
gram office was set up with autonomous capabil- 
ity to manage SE&I and direct the development 
contractor. 

With the advent of the Apollo program, SE&I 
was again managed from the project offices at 
the development Centers. The project offices 
used specialized technical capability from the 
Center functional organizations and prime con- 
tractors and initiated the practice of hiring sup- 
port contractors to assist in implementing SE&I. 
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After the Apollo I fire, a review committee was 
established to determine the cause of the fire 
and recommend modifications to the program. 
One of the recommendations made was that 
NASA acquire a technical integration and engi- 
neering support contractor to assist in accom- 
plishing SE&I activity. The Washington pro- 
gram office selected Boeing as the contractor 
and managed the contract for this activity; how- 
ever, a large portion of the manpower was locat- 
ed at the development Centers. The contractor’s 
responsibilities included monitoring the devel- 
opment and operational activities at the Cen- 
ters, forming integrated assessments of the ac- 
tivity, and making recommendations to the pro- 
gram director for improvements. As the pro- 
gram matured, the contract focus was changed, 
and the contractor provided a significant num- 
ber of personnel to directly support the centers 
in SE&I and systems activities. 

With the initiation of the Space Shuttle program 
and the adoption of the lead Center concept, it 


was decided to manage the Level II integration 
activity, including SE&I, by providing a small 
management core within the program office and 
using many of the Center’s functional organiza- 
tions to provide technical support in a matrix 
fashion. At the Johnson Space Center (JSC), the 
lead person from the functional organization 
was generally a branch head or an assistant di- 
vision chief. Therefore, JSC had a relatively 
large staff to draw from to provide the specific 
technical expertise and the level of effort needed 
to accomplish a given task. 

The Space Station Freedom program was start- 
ed using the Space Shuttle program as a model. 
As the lead Center, JSC managed integration. 
Later, the Level II function was moved near 
Washington, D.C., under the deputy program di- 
rector, and an independent contractor was 
brought in to assist the integration process. The 
Space Station Freedom program's management 
organization is discussed in more detail in the 
next section. 


Figure 1 - Apollo Program Organization 
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Program Management Organizational 
Structure 

A single NASA Center largely managed early 
NASA manned space flight programs, which al- 
lowed for a relatively simple organizational 
structure to accomplish program integration. 
JSC, then called Manned Space Center (MSC), 
managed both developmental and flight oper- 
ational aspects of the Mercury and Gemini pro- 
grams with the checkout and preflight testing 
being performed by support elements at Cape 
Canaveral. 

The Apollo program became organizationally 
more complex (see Figure 1). The spacecraft de- 
velopment was managed by JSC; the launch ve- 
hicle development by the Marshall Space Flight 
Center (MSFC); the prelaunch activities by the 
Kennedy Space Center (KSC), by then an inde- 
pendent NASA Center; and the flight operations 
by JSC. In all of these programs, the responsibil- 
ity for the development of the flight hardware 


was delegated to the Centers, and the interfaces 
between projects were intentionally kept as sim- 
ple as possible. The Washington office, under di- 
rection of the program director, was responsible 
for overall direction of the program including 
budgetary allocations, congressional relations, 
and management of development issues be- 
tween the project offices at the different Centers. 
The actual integration activity (SE&I) was co- 
ordinated by a series of panels and working 
groups in which individuals from the Washing- 
ton program office served as either chairperson 
or members, with the program director oversee- 
ing the activity. In the early programs (Mercury 
and Gemini), this activity was the responsibility 
of a single Center, and the Washington office 
was coordinated in an informal manner, but by 
the end of the Apollo program, the management 
of the panel and working group activity was rel- 
atively formal. In all of these programs the Cen- 
ter directors took an active part and personally 
felt responsible for the technical excellence of 
the work performed by their Centers. This in- 


Figure 2 - Space Shuttle Program Organization 


Level I 
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tercenter involvement was accomplished pri- 
marily through the management council and 
major program reviews where Center directors 
personally participated in major decisions. 

In part of the Apollo program, the Washington 
office retained the responsibility for performing 
the SE&I activity with actual work being led by 
Bellcom, a division of Bell Laboratories. Ulti- 
mately, this approach was abandoned in part be- 
cause much of the Center director’s responsi- 
bility was lost, and an adversarial relationship 
between the program director and the Center or- 
ganizations developed. The execution of the 
SE&I was returned to the Centers with manage- 
ment and coordination of intercenter activities 
achieved through the use of working groups, 
panels, and management reviews. 

At the outset of the Space Shuttle program (see 
Figure 2), the management of SE&I was chang- 
ed. Some of the more important changes were: 
adoption of the lead Center management con- 
cept, in which one of the participating Centers 


was delegated the management of program- 
level integration including SE&I activities; the 
adoption of a configuration with functional and 
physical interfaces of much greater complexity; 
and the employment of one of the major hard- 
ware development contractors as the integration 
support contractor. The complex interfaces 
made SE&I activity voluminous and involved 
and required the commitment of a larger per- 
centage of the program resources to this activ- 
ity. 

The Space Station Freedom program was struc- 
tured so that the interface activity between the 
work packages was even more complex than 
that of the Space Shuttle program. Initially, the 
lead Center approach to SE&I activity was 
adopted, but the implementation was not effec- 
tive. As a result of recommendations made by 
study groups and the committee reviewing the 
Challenger accident, it was decided to transfer 
the responsibility for program integration activ- 
ity, including SE&I, to the deputy program di- 
rector in Reston, Virginia, and to bring on a con- 


Figure 3 - Space Station Freedom Program Organization 
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tractor to provide program integration support 
(see Figure 3). Contractors having significant 
hardware development contracts were excluded 
from the contract competition. The first ap- 
proach was to provide detailed management of 
SE&I activity by the Reston civil service person- 
nel with the integration contractor providing 
support in executing the activity. Additionally, 
it was thought that much of the technical inte- 
gration activity could be accomplished by hav- 
ing the work package contractors negotiate the 
definition and execution of much of the detailed 
integration process directly between them- 
selves. This proved ineffective, however, be- 
cause there was no clear lead responsibility and 
no clear way to resolve differences. As a result, 
because of the complexity of the program inte- 
gration and the lack of in-depth backup capabil- 
ity, this management approach has not been 
completely effective. 

Recently, it was decided to give the integration 
support contractor direct responsibility for the 
integration of the program but without author- 
ity to directly manage the work packages or 
their contractors. In an attempt to obtain more 
in-depth capability, the program director and 
deputy program director decided to execute the 
systems integration portion of the SE&I activity 
at two of the field centers with the deputy direc- 
tor for integration physically located at one of 
the Centers. Since these functions were still re- 
tained organizationally within the program of- 
fice, they were under the control of the deputy 
program director and, at the same time, had the 
advantage of drawing from the technical capa- 
bility residing at the Centers. Simultaneously, 
the integrating contractor’s personnel at the 
Centers was materially increased in both re- 
sponsibility and quantity. 

Growing Program Complexity 

One of the major factors that determines the ef- 
ficiency of the integration of a program is the 
methodology used in delegating the engineering 
and development responsibilities to the project 
offices at the field Centers. It has been found 
that less complex organizational structures and 
simple interfaces are extremely important to al- 
low efficient management of the SE&I activi- 


ties. Each of NASA’s manned space programs 
has been organizationally more complex than its 
predecessor and has had more complex inter- 
faces. In both the Mercury and Gemini pro- 
grams, the flight elements were divided into two 
parts, spacecraft and launch vehicle, and the 
physical and functional interfaces between the 
two were quite simple. The induced environ- 
mental interfaces were somewhat more complex 
but readily amenable to experimental and ana- 
lytical determination. 

The Apollo program involved a major increase 
in program complexity. The spacecraft was di- 
vided into two project offices while the launch 
vehicle was divided into four project offices. By 
assigning the four launch vehicle projects to the 
same development center (MSFC), the integra- 
tion between launch vehicle stages could be ac- 
complished at the Center level. Similarly, both 
spacecraft projects were assigned to one Center 
(JSC) for the same reason. The physical and 
functional interfaces between the spacecraft and 
launch vehicle, and hence between development 
Centers, was relatively simple. In a paper writ- 
ten in 1971 titled What Made Apollo a Success, 
George Low stated: 

Another important design rule, which we 
have not discussed as often as we should, 
reads: Minimize functional interfaces be- 
tween complex pieces of hardware. Examples 
in Apollo include the interfaces between the 
spacecraft and launch vehicle and between 
the command module and the lunar module. 
Only some 100 wires link the Saturn launch 
vehicle and the Apollo spacecraft, and most 
of these have to do with the emergency detec- 
tion system. The reason that this number 
could not be even smaller is twofold: redun- 
dant circuits are employed, and the electrical 
power always comes from the module or 
stage where a function is to be performed. 
For example, the closing of relays in the 
launch vehicle could, in an automatic abort 
mode, fire the spacecraft escape motor. But 
the electrical power to do this, by design, 
originates in the spacecraft batteries. The 
main point is that a single man can fully un- 
derstand this interface and can cope with all 
the effects of a change on either side of the in- 
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terface. If there had been 10 times as many 
wires, it probably would have taken a hun- 
dred (or a thousand? ) times as many people 
to handle the interface. 

However, the operational complexity of the 
Apollo vehicle demanded a more extensive inte- 
gration activity between the Centers, and for 
the first time posed the problem of accomplish- 
ing detailed technical coordination between 
Centers. 

One of the basic tenets of the Space Shuttle pro- 
gram was to have an integrated vehicle that 
would recover the most expensive elements of 
the system for reuse. This led to a design concept 
that placed a great majority of the electronics 
and major components of the main propulsion 
systems in the orbiter. This design concept led to 
very large increases in interface complexity be- 
tween the program elements and, more impor- 
tantly, between development Centers. For in- 
stance, the number of electrical wires running 
between the external tank and the orbiter was 
more than an order of magnitude greater than 
between the spacecraft and launch vehicle of 
Apollo, and for the first item, major fluid sys- 
tems ran across the interfaces. This represented 
a formidable increase in the effort required to 
successfully accomplish the SE&I activity. As 
previously noted, the new program management 
structure, shown in Figure 1, was adopted to ac- 
commodate the increase. The accomplishment of 
program level SE&I was given to a “lead Cen- 
ter.” The program director at headquarters was 
still responsible for program budgetary control, 
Congressional relations and a technical staff 
sufficient to assure that the program technical 
activity was being properly implemented. At 
JSC, which was the lead Center for the Space 
Shuttle program, a Level II program office was 
established totally separate from the Level III 
orbiter project office, located at the same Center. 

The development of the flight hardware was 
delegated to four project offices with the orbiter 
office located at JSC, as mentioned above, and 
the other three, the Space Shuttle main engine 
office, the external tank office, and solid rocket 
booster office, located at MSFC. In addition to 
the hardware development project offices, a 


prelaunch processing office was formed at KSC. 
All of the project offices reported to the Level II 
program manager for all programmatic dir- 
ection except budget allocation, which was re- 
tained by the program director at headquarters. 

The SE&I activity was delegated to the Systems 
Integration Office located within the JSC Level 
II Office. The orbiter contractor, Rockwell 
International, was selected to be the integration 
support contractor, but to increase objectivity, 
the integration activity was made a separate 
exhibit to the contract and technical direction 
was delegated to the Level II Systems 
Integration Office. The MSFC Space Shuttle 
Project Office appointed an integration manager 
to manage the integration of the Marshall Space 
Shuttle Projects and to serve as the primary 
interface to the Level II Systems Integration 
Office. 

The flight hardware developmental delegation 
of the Space Station Freedom program was 
formulated in an even more complex manner 
(see Figure 4). End-to-end developmental 
responsibility for each of the major functional 
systems was delegated to one of four project 
offices called work package offices; the 
responsibility for assembling and delivering the 
flight hardware was broken down by launch 
elements, again assigned to one of the work 
package offices. Each of these launch elements 
incorporated components of most of the 
distributed systems, necessitating the transfer 
of an extremely large number of hardware and 
software items between work packages prior to 
their delivery to the government. This resulted 
in another major increase in the complexity of 
the program-level SE&I process and directly 
contributed to the difficulty of implementing a 
satisfactory SE&I process in the Space Station 
Freedom program. 

SE&I Scenario 

As a program develops from concept to 
operational status, the characteristics of the 
SE&I activity vary greatly. Early in the 
program, conceptual stage SE&I is intimately 
involved in defining systems that will meet the 
overall program objectives and in evaluating the 
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Figure 4 - Space Station Freedom Integration Activities 


relative merits of each. This is usually 
accomplished in NASA manned programs by the 
civil service organizations, often in concert with 
Phase A/B contracts with industry. 

After the general systems specification has been 
developed and a detailed evaluation of system 
concepts completed, SE&I provides a lead in the 
preparation of the procurement specifications 
for the Phase C/D activity and is usually directly 
involved in the source selection process. After 
award of the Phase C/D contracts and final se- 
lection of the design approach chosen for imple- 
mentation, SE&I is responsible for preparing 
system level technical specifications, which de- 
fine the performance requirements to be satis- 
fied by each of the major program elements. 

SE&I then develops the system characterization 
process to be used (discussed in more detail 
later) and starts an initial analysis cycle. The 
results of this cycle are extremely important in 
verifying the validity of the system technical 
specifications and providing a technical basis for 
conducting the Program Requirements Review 
(PRR). After completion of the PRR and 
updating of the technical specifications, SE&I 
starts the definition of the interface control 


document tree and the initial drafts of the 
documents. Another system characterization 
cycle is started based on the updated specifi- 
cations and the hardware/software concepts 
chosen to assess the adequacy of the proposed 
preliminary design approach. 

By this time in the program, the ad hoc organi- 
zational structure should be well in place and 
functioning on a routine basis. The communica- 
tion and management overview provided by this 
structure of working groups, panels, and re- 
views is central to accomplishing horizontal in- 
tegration among the project offices and is dis- 
cussed in more detail in a later section. 

In preparation for the preliminary design 
review (PDR), SE&I defines the minimum 
content required in the PDR data packages and 
is responsible for preparing system-level 
documents supporting the Integrated System 
PDR. During the PDR process, SE&I represen- 
tatives participate in the project-level reviews 
with particular emphasis on the compliance of 
the project to the system-level requirements. 
During the integrated system PDR, emphasis is 
placed on assuring that the preliminary designs 
meet the operational requirements of the 
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program. The SE&I organization is intimately 
involved with the evaluation and disposition of 
review item discrepancies (RIDS) that are 
submitted during the review. 

As a result of the PDR process, changes to the 
requirements and modifications to the prelimi- 
nary design of the elements are incorporated. A 
new characterization cycle is then initiated to 
evaluate the compatibility between the modified 
requirements and proposed system capabilities. 
At this time, the drafts of the interface control 
documents are expanded and quantitative detail 
added to assure that they are mature enough to 
become baseline requirements in the program. 
This maturation process inevitably adds a sig- 
nificant number of changes to the baseline. 

In a similar manner, the verification plans of 
the elements and the integrated system are 
refined and baselined. The responsibility for 
executing the test and analysis required by the 
integrated system verification plan is delegated 
to appropriate organizations who then prepare 
detailed plans for accomplishing the assigned 
portions of the verification. 

Detailed mission operational scenarios and 
timelines are prepared by the operations or- 
ganizations, and the operations and SE&I 
organizations jointly conduct an analysis of the 
system capabilities to support the scenarios. 
Concurrently, the acceptance test and prelaunch 
operations requirements and plans are prepared 
and delegated for execution. 

In preparation for the critical design review 
(CDR), another system characterization cycle is 
performed based upon the detailed design of the 
elements. This cycle typically uses mature 
models to synthesize the hardware and software 
systems and also incorporates the results of tests 
performed to that time. SE&I participates in the 
conduct of the CDR in a manner similar to that 
of the PDR. After completion of the CDR, the 
system requirements and design changes 
resulting from the CDR are incorporated into 
the documentation, and another complete or 
partial system characterization cycle is 
performed to validate the decisions made during 
CDR. 


After CDR, the primary activity of the SE&I or- 
ganization is to analyze test results and conduct 
analysis to verify the capability of the system 
that is being manufactured. Particular empha- 
sis is given to verifying the interface character- 
istics of the elements as defined by the interface 
control documents. This activity directly sup- 
ports the preparation for the design certification 
review (DCR) and provides interface informa- 
tion necessary to allow acceptance of the system 
hardware and software by the government. 

The DCR is conducted similar to the PDR and 
CDR but addresses the as-built hardware and 
software. Successful completion of the DCR 
certifies the acceptability of the as-built ele- 
ments and the ability to be integrated into an 
overall system that will satisfy the initial 
program operations requirements. Final 
operational certification of the system is 
obtained by a combination of the DCR process 
and analysis of information obtained during 
early flight operation of the system. 

SE&I organization participation throughout the 
program development cycle provides them a 
unique capability to support operational plan- 
ning and real time operations. SE&I is the 
repository of corporate knowledge of the details 
of the system capability, which is vital to the 
effective and efficient operation of the system. 

Relationship of SE&I to Other Program 
Functions 

To effectively accomplish the SE&I task, the 
SE&I management organization must maintain 
good communications and obtain the support of 
other program office organizations. Some of the 
more important interactions are discussed be- 
low. 

Configuration Management 

The interaction between SE&I and config- 
uration management is particularly strong. As 
the developers and keepers of the systems 
specifications, SE&I has an interface with the 
configuration management function that is 
extremely active throughout the life of the 
program. The SE&I office recommends the 
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baselining of the technical requirements as they 
become sufficiently mature and then serves as 
the office of primary responsibility for defining 
and evaluating most of the proposed changes to 
this baseline. The SE&I office, after proper 
coordination throughout the integration 
function, also recommends the processing of 
non-controversial changes outside of the formal 
control board meetings, where appropriate. This 
results in significantly reducing the board’s 
workload and conserves the time of the key 
managers who are members of the Change 
Control Board. Significant issues are referred to 
the board, and the SE&I office presents its 
analysis of the issues involved and makes 
appropriate recommendations. 

Program Control 

SE&I supports the program control function in 
the development of program schedules and bud- 
gets. The key to making this support effective is 
the use of SE&I logic networks and estimates of 
the manpower required to accomplish activities. 
Because of its interdisciplinary nature, SE&I 
can assist in planning activities in many 
program areas. 

Early in the program, SE&I helps define the 
content and schedule milestones for each of the 
projects so the coherent development of project- 
level schedules and cost estimates can be achiev- 
ed. In addition to supporting program control, 
SE&I provides program control with the engin- 
eering master schedules (EMS) and associated 
budget estimates for incorporation in the overall 
schedule and budget system. SE&I also works 
with program control in the planning of major 
program reviews, provides technical leadership 
during the conduct of the reviews, and frequent- 
ly chairs the screening groups and preboards. 

Operations 

In all of the NASA manned space programs to 
date, the SE&I function has been managed in a 
different organization from the operations defi- 
nition and planning function. Although this is 
undoubtedly the best choice in the later phases 
of the program, it may result in a less thorough 
incorporation of operational requirements in the 


systems specifications and other SE&I products 
early in the program. It may be desirable to con- 
sider combining the management of SE&I and 
operations in the same office early in the pro- 
gram and then separating them at a later time, 
such as completion of the predesign review 
(PDR). The stated reason for separating the 
functions in the past has been that they serve as 
a check-in-balance on each other; however; this 
causes disconnects in the detailed interfaces be- 
tween the two functions. 

SR&QA 

The interactions between SE&I and the System 
Reliability and Quality Assurance (SR&QA) 
functions depends on how the delegation of 
responsibility for executing the program is 
approached. If a large part of the SR&QA 
activity is accomplished within the SR&QA or- 
ganization, then the interface with SE&I is 
mostly that of using SE&I as a reservoir of 
information or to perform specific tasks as 
requested by SR&QA. However, if the SR&QA 
office is responsible for setting the requirements 
for the SR&QA activities and evaluating the 
outcome while other organizations such as SE&I 
are delegated the responsibility for executing 
the work, then the interface becomes one of 
SR&QA defining and obtaining baseline 
approval of task requirements, monitoring 
execution of the task by SE&I, and evaluating 
the results to assure satisfactory achievement. 

The former mode of operation was exemplified 
during early portions of the Apollo program, 
where the SR&QA activities were largely 
accomplished within the SR&QA office using 
basic engineering information obtained from 
SE&I and other program organizational offices. 
Later in the Apollo program, the second mode of 
operation was adopted, in which engineering 
offices, primarily SE&I, actually performed the 
work and made a first-level analysis prior to 
formally transmitting the results to SR&QA for 
authentication. This latter mode of operation 
was felt to be more effective primarily because 
problems and discrepancies were often 
discovered by the originating engineering office 
and corrected even before the task was 
completed. 
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SE&I Execution 

Many techniques have been developed in past 
NASA manned programs that have proven ef- 
fective and have become an integral part of im- 
plementing SE&I activities. The following para- 
graphs describe some of the more important 
techniques to assist those planning and imple- 
menting new programs. 

Importance of SE&I Early in a Program 

Comprehensive SE&I support is crucial in the 
early stages of complex programs to assist in 
determining the architecture to be used in 
delegating project responsibility. This is 
accomplished by dividing the program into the 
next lower level of management, the project 
offices. The primary outputs are comprehensive 
and clear program requirement specifications, 
identification of major programmatic interfaces, 
development of the ad hoc SE&I management 
structure, definition of operating concepts, and 
preparation of initial specifications for the 
hardware to be delegated to each project office. 

The SE&I organization is responsible for 
managing technical integration both vertically 
between different levels of the management or- 
ganizational structure and horizontally across 
the organizations at each level. To efficiently 
achieve both dimensions of integration, it is nec- 
essary to develop logic diagrams of the major 
SE&I activities to be accomplished by each of 
the organizational elements and then to deter- 
mine the interrelationships between them. By 
developing these diagrams and playing them 
against different organizational structures, it is 
possible to evaluate the proposed organizations 
in simple terms and easily define the interac- 
tions between the organizational elements, thus 
helping to choose the most efficient manage- 
ment structure. The importance of the logic dia- 
grams will be discussed later. 

Development and Use of Ad hoc 
Integration Structure 

To manage the definition and implementation of 
the SE&I activities in manned space programs, 
NASA has developed an effective ad hoc organ- 


izational structure. The structure consists of a 
series of reviews, panels, and working groups 
that address the definition and management of 
integration functions throughout the program. 
Each of these organizations has membership re- 
presenting all of the organizations interested in 
the particular integration function being man- 
aged. In the Space Station Freedom program, 
the working group structure is formed by techni- 
cal disciplines and distributed systems, such as 
Guidance, Navigation and Control (GN&C), Ro- 
botics, and Loads and Dynamics. The panels are 
formed to address specific programmatic man- 
agement areas (i.e., assembly requirements and 
stage definition, system design integration, and 
element design integration) that span a number 
of organizations. The reviews are formed to ad- 
dress relatively broad program areas as shown 
in Figure 5. 

Each of these organizations is responsible for de- 
veloping the integration plan in its area of re- 
sponsibility, monitoring the execution of the 
tasks, identifying problem areas, and either re- 

Figure 5 - Station Technical Review Structure 1990 


PMIR Program Management Integration 
ER Engineering 

IMR Integration Management 
MIR Mission Integration 

EIR Element Integration 

- SIR System Integration 


PMIR 

Bensimon 






EIR 

Sisson 



SIR 

Goree 




16 



solving them or submitting them to the overall 
program management structure for resolution. 
Many benefits result from the face-to-face meet- 
ings and interchange of information among 
peers in these organizations. Although these or- 
ganizations by their nature do not perform 
work, the members, by working back through 
their functional organizations, greatly influence 
the work being accomplished in their particular 
areas of expertise. As rapport is developed be- 
tween members, many potential problems and 
issues are identified and resolved without the 
need for referral to the formal management de- 
cision channels. In addition, the quality of the 
work materially improves. This ad hoc organiza- 
tional structure also provides obvious places for 
program elements to present issues of any given 
nature for deliberation and resolution. All of the 
panels and working groups support each of the 
reviews as needed and submit their open issues 
to the most appropriate review for resolution. 

The reviews address broad issues and serve as a 
communication channel between the panels and 
working groups. Since the reviews are broad 
and cover all of the panels and working groups, 
they provide an excellent way to assess and rec- 
ommend activities that address the interdisci- 
plinary aspects of the program. 

Chairpeople of the panels and working groups 
are the best qualified individuals available in 
the particular discipline, and only secondary 
consideration is given to selecting a person from 
a specific organizational element. As a result of 
their recognized stature, the chairpeople provide 
leadership, which makes their recommenda- 
tions and decisions more readily acceptable. The 
panels and working groups also request outside 
expertise when needed; such outside inputs are 
filtered by the panels and working groups prior 
to making a recommendation to the reviews or 
other management organizations. 

Internal vs. Matrix SE&I Staffing 

As already noted, SE&I activity was staffed and 
accomplished in different ways in the different 
NASA manned programs. At times, in the early 
manned space programs, the personnel required 
to accomplish the SE&I activity were assigned 
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directly to the program and project offices. At 
other times, during the Apollo and Shuttle 
programs, the program office had only the 
people necessary to manage the SE&I activity, 
and most of the work was accomplished by 
technical experts assigned from the Center’s 
functional organizations in a matrix fashion. 

Although each had its advantages and disad- 
vantages, the matrix approach in general ap- 
pears to have had more advantages, one of the 
most important being that the manpower can be 
increased or decreased as needed by pulling 
support from the matrix organizations without 
requiring reassignment of the people involved. 
The primary disadvantage is that the leader of a 
particular area does not report functionally to 
the program or project office; therefore, the line 
of direction is not as strong, a factor that is in- 
versely proportional to the working relationship 
between the organizations. 

In the Space Shuttle program, this relationship 
and the matrix approach worked well. In other 
programs, the relationship was not as good and 
direction through the matrix was less effective. 
On occasion, program management appointed 
all panel and working group chairpeople from 
the program office staff, giving less regard to the 
personal qualifications of the individuals. This 
has led to a marked decrease in the stature of 
the ad hoc structure, which resulted in a lack of 
support from the functional organizations and a 
decrease in the quality of the integration activ- 
ity and products. As in many areas of SE&I, ef- 
fective implementation relies heavily on the 
quality of the leadership and the maintenance of 
free and open communications between the or- 
ganizations involved. 

Logic Networks 

As the NASA manned space programs have 
become increasingly complex, it has become 
difficult to define the specific content and tasks 
needed to accomplish the SE&I function. 
Central to the development of a comprehensive 
SE&I plan is the development of detailed logic 
networks. These networks form the basis for 
planning, executing and evaluating SE&I 
activities. 
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As used in the Space Shuttle program, these 
logic networks covered all of the SE&I activities 
that had to be accomplished by all elements of 
the program organization. Thus, these networks 
were able to interrelate SE&I activities both 
vertically and horizontally throughout the pro- 
gram management structure. The basic sum- 
mary logic networks were developed for the en- 
tire program duration to identify all major ac- 
tivities required as a function of time and were 
instrumental in developing cost and manpower 
forecasts for the entire duration of the program. 
Detailed logic networks were then prepared in 
the Shuttle program for 12 months, identifying 
in greater detail the specific activities to be ac- 
complished by each organizational element dur- 
ing that period. The networks were revised ev- 
ery six months to extend the detail planning ho- 
rizon, and in addition, the summary networks 
were reviewed and modified as needed on an an- 
nual basis. The logic networks were a primary 
input to the development of the engineering 
master schedules discussed next. 

Engineering Master Schedules (EMS) and 
Associated Dictionary 

The activities identified in the SE&I integration 
logic networks were then assigned to specific 
organizations for execution and presented as a 
schedule for each organization involved. By 
using a numbering system for the activities, a 
correlation between the logic network and the 
schedule could be easily provided. Preparation 
of the schedules allowed cost and manpower 
estimates to be prepared for each organization 
and provided an excellent means of updating 
and managing the activities in real time. 

Associated with the engineering master 
schedule (EMS), a dictionary was prepared with 
an entry for each activity. Each entry identified 
all input information required to allow the 
accomplishment of the activity; described the 
contents of the products; and identified the pri- 
mary user of each product, the scheduled 
completion date, and the person responsible for 
preparing the product. The EMS and the 
dictionary were the primary tools for defining 
and communicating SE&I activities throughout 
the entire program structure. 


As would be expected, the basic content of the 
EMS changes character over the life of the 
program and accordingly requires a varying mix 
of technical capabilities as a function of time. 
Early in the program, the activities are 
primarily of a design nature and involve a large 
number of trade studies and the development of 
synthesis tools to be used in evaluating the 
capabilities of the proposed design. As the 
program matures and the design solidifies, the 
activities become more involved with exercising 
the system models, conducting tests, and ana- 
lyzing data. As the flight phase approaches, the 
activities are predominated by operational 
considerations, including the development of 
operational data books, mission requirements, 
certification of system readiness, and support of 
mission planning and real time mission 
operations. 

System Characterization Process 

A major SE&I activity throughout the program 
life span is the assessment of the capability of 
the system to meet specified requirements. In 
the NASA manned space program, this has been 
accomplished primarily by synthesizing the ve- 
hicle characterizations in the form of either 
models or simulations and then developing de- 
tailed performance characterizations by exercis- 
ing the models against selected mission time- 
lines and significant mission events. 

The methodology used in performing the system 
synthesis is central to the development of the 
logic networks and schedules described earlier. 
An examination of the system usually reveals 
scenarios useful in conducting the overall sys- 
tem evaluation, and after selecting the most de- 
sirable scenario, it is used to form the nucleus of 
the overall SE&I logic. In the Space Shuttle pro- 
gram, the scenario chosen was (1) developing 
the necessary models and simulations, (2) deter- 
mining the structural modal characteristics, (3) 
determining the loads on each of the system ele- 
ments, and (4) performing stress analysis of the 
system when subjected to these loads. Using this 
scenario it was relatively easy to define and in- 
terrelate the SE&I activities of other disciplines, 
such as GN&C, propulsion, and thermal, among 
others. After definition of all of the required ac- 
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the models to be used, the mission events to be 
analyzed, and a definition of the configuration to 
be used. The sequence described above formed 
an analysis cycle of a specific configuration sub- 
jected to specific operational requirements and, 
in the Shuttle program, was termed an integrat- 
ed vehicle baseline characterization cycle 
(IVBC). In this article, the capability assess- 
ment is referred to as a system characterization 
cycle. As previously described in the SE&I sce- 
nario, several characterization cycles are needed 
during the life of the program. As the program 
matures, the cycles are characterized by having 
additional synthesis detail, more definitive con- 
figuration information, and better operational 
information. 

At the completion of each of the characterization 
cycles, system deficiencies are identified and 
modifications to either the system specifications 
or the requirements are made. For program 
management purposes, it is usually convenient 
to schedule the completion of one of the 
characterization cycles to occur just prior to each 
of the major program level review milestones. 

Program Reviews 

SE&I has a large input to each of the program- 
level reviews, such as system requirements 
review, predesign review, critical design review, 
design certification review, and flight readiness 
reviews. As mentioned above, completion of one 
of the system characterization cycles is an 
excellent indicator of whether the system design 
meets the specified requirements, and the 
engineering master schedule gives a graphic 
representation of the integration progress being 
achieved. Reports produced by the SE&I 
activity — such as resource allocation status and 
margins interface control document status, 
design reference mission maturity, and system 
operational data books — give a good indication 
of the maturity of the element participation in 
the system-level SE&I process. 

Design Reference Missions (DRM) 

Most of the manned space programs had to be 
capable of performing a relatively large number 
of diverse missions, and the specifications are 


written in a manner to provide hardware and 
software systems and elements that are flexible 
enough to satisfy all of the missions. For analyt- 
ical purposes, however, it is convenient to define 
and adopt one or more design reference missions 
(DRMs) that stress all of the system’s capabil- 
ities to a significant extent. The DRMs are used 
as the primary mission requirements in the sys- 
tem characterization cycles, and in evaluating 
the ability to meet performance specifications. 
In addition to evaluating the baselined configu- 
ration against the DRMs, other specification re- 
quirements are evaluated by the accomplish- 
ment of specific analyses or tests as necessary. 

The DRMs also allow the user community to 
evaluate whether the system is capable of meet- 
ing specific user needs and whether these needs 
are specifically in the system specifications. The 
DRM is also used by mission planners to deter- 
mine the system’s capability of performing any 
specific mission under consideration. 

Verification 

Verification plays a major role in program 
planning and in the ultimate cost of the system. 
Most of the verification is delegated to projects; 
however, SE&I is responsible for identifying 
overall verification requirements and specifical- 
ly, identifying system-level verification test and 
simulations, which frequently require 
specialized facilities and significant amounts of 
system hardware and software. These system- 
level verification tests are frequently both 
complex and expensive, and planning for them 
needs to be started very early in the program. 
The system-level verification network is de- 
veloped as an integral part of the program SE&I 
logic networks and baselined early in the 
program. 

Final verification of some system requirements 
can only be accomplished in the real flight envi- 
ronment, and these are demonstrated in early 
operations before final certification of system 
operational capability is accomplished. It is also 
important to integrate the system-level verifica- 
tion planning and the operations planning to 
gain the maximum possible synergy between 
system verification and operational training. 
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In the manned space programs, all of the major 
system-level verification tests were assigned to 
program or functional organizational elements 
other than SE&I for implementation. This helps 
assure that the management of SE&I can re- 
main objective in the evaluation of overall certi- 
fication adequacy. 

DCR Process 

One of the more significant activities of SE&I is 
its role in the design certification of the system 
prior to the start of the flight operations and 
then again later, prior to committing the system 
to operating throughout the entire design enve- 
lope. SE&I is instrumental in setting the overall 
requirements for the DCR and is directly re- 
sponsible for the system-level portion of the re- 
view. This process uses synthesis of the as-built 
vehicle hardware and software capabilities and 
results of tests and analysis. The results of the 
design certification process also form the basis 
for the system operational data books that are 
used in planning and conducting the operational 
phase of the program. The DCR requires that all 
system requirements be evaluated against all of 
the as-built system capabilities, and where pos- 
sible, the system margins are quantified to as- 
sist the operations organization in planning and 
conducting flight operations. 

ICD Development 

As the program management organizational 
structure and the delegation of the responsibil- 
ity for developing hardware and software are 
made, it is necessary to start the development of 
the interface control document (ICD) tree, which 
identifies each required ICD and the content to 
be presented. As previously noted, the division 
of program activities to minimize the number 
and complexity of interfaces has a strong influ- 
ence on the overall program cost and the ability 
of the program to meet schedules. The early de- 
velopment of strawman ICD trees can greatly 
assist in optimizing the overall program man- 
agement structure. 


As the program progresses and the system con- 
figuration becomes better defined, the content of 


each ICD is developed in more detail and ICD 
working groups are formed to quantify the envi- 
ronmental, physical, functional, and operational 
characteristics in detail. In most of the manned 
programs, the ICDs have been baselined at a rel- 
atively early point in the program and have usu- 
ally contained a large number of TBDs (to be de- 
termined). After baselining the ICDs, working 
groups then continue their work to arrive at spe- 
cific values for each of the TBDs and to contin- 
ually assess the adequacy of the ICDs as the de- 
sign matures. 

The ICDs are primary documents at each pro- 
gram review and provide a basis for evaluating 
the adequacy of the items being reviewed to sat- 
isfactorily function as part of the total system. 

Program Management Organizational 
Structure 

The efficiency of program management is 
greatly influenced by the organizational struc- 
ture selected. Organizational structures that are 
compact and simple are essential to promote 
effective program management. Compactness is 
measured vertically by the number of levels of 
the program management organization and hor- 
izontally by the number of organizations at each 
level. Each organizational element added sig- 
nificantly increases the manpower and costs of 
achieving program integration, including SE&I. 
If each organizational element must interface 
with all others in the program, the number of 
interfaces increases rapidly as organizations are 
added. Adding management levels increases the 
complexity for delegating the execution of the 
program. This factor was evident to the 
Augustine Commission in their recent summary 
report The Future of the U.S. Space Program, in 
which they recommended that “multicenter 
projects be avoided wherever possible, but when 
this is not practical, a strong and independent 
project office reporting to headquarters be 
established near the Center having the 
principal share of the work for that project; and 
that this project office have a systems en- 
gineering staff and full budget authority.” 

In addition to keeping the management struc- 
ture compact, it is also very important to select 
an 
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an architecture that divides the program into 
project offices so that the interfaces between 
projects are as simple as possible and that the 
delegation is all encompassing. In so far as 
possible, all of the deliverable hardware 
assigned to a given project should be the 
responsibility of that project to design and 
manufacture. In all of the manned programs 
prior to the Space Station, there was little 
transfer of hardware and software between 
projects with one exception, that being the 
development flight instrumentation in the 
Apollo program. 

Early in the Apollo program, a decision was 
made to establish a civil service project office to 
develop, procure and deliver the specialized 
development flight instrumentation to the 
prime spacecraft contractors for installation and 
integration in the early spacecraft. Coordination 
of the very large volume of interface information 
required the development and maintenance of 
the complex bilateral schedules and support 
required. 

The complexity of providing support after the 
transfer of instrumentation was a significant 
management problem throughout the entire 
time that the development flight instrument 
was used. In view of the extremely large number 
of hardware and software items that must be 
passed between work packages, it will be 
difficult for the Space Station Freedom program 
to develop, coordinate, and maintain all of the 
interface information required. 

Objectivity in Management 

To promote objectivity in managing SE&I, one 
of the basic ground rules in the Space Shuttle 
program was that the SE&I function would not 
be responsible for the development of any flight 
hardware or software products; thus they had no 
conflicting pressure to make their development 
job easier at the expense of another 
organization. It was found that any bias, either 
perceived or real, immediately brings the 
objectivity of management into question and 
rapidly destroys the confidence between 
organizational elements. 


Need for Good Communication 

The nature of SE&I is such that most of the 
program elements and many other agency 
organizations are involved in the execution of 
SE&I tasks. To facilitate accomplishment of the 
work, the importance of free and open 
communication cannot be overly stressed. One 
of the ways of accomplishing this is “to live in a 
glass house.” All decisions and, of equal 
importance, the logic behind those decisions 
must be communicated to all parties involved if 
they are to understand their role and how it fits 
into the overall picture. All parties must feel 
that their inputs are included in the decision- 
making process. 

This openness, and the accompanying feeling of 
vulnerability, is not welcomed and requires 
faith and confidence between the organizations 
involved. The fact that mistakes will be made 
must be accepted, and all organizations involved 
must constructively assist in correcting them. 
Frequent open meetings of the ad hoc 
organizational elements described above have 
proven to be an effective tool in developing 
rapport between peers and communicating 
information and decisions throughout the 
program structure. As noted earlier, however, 
such meetings become increasingly time- 
consuming and expensive as the complexity of 
the organizational structure is increased. 

Importance of Margins 

At the time programs are initiated, they are fre- 
quently sold on the basis of optimistic estimates 
of performance capability, cost, and schedules. 
This often results in reducing margins to low 
levels at program initiation and solving early 
program costs and schedule problems by reduc- 
ing weight, power, and other resource margins. 
As a consequence, margins are reduced to zero 
or negative values early in the program, making 
it necessary to modify the program to either re- 
duce requirements or introduce program 
changes that will re-establish positive margins. 

The recovery of the margin inevitably leads to 
significantly higher ultimate program costs in 
both dollars and days. Minimum life cycle costs 
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are achieved by holding relatively large mar- 
gins early in the program and then allowing 
them to be expended at a prudent rate during 
the program life cycle. 

Things That Have Worked Well 

In the management of the manned space pro- 
grams’ SE&I activities, several approaches have 
been particularly successful. Some of the more 
important, briefly summarized below, have been 
discussed previously in the paper but are re- 
addressed here because of their assistance in the 
management of SE&I. 

Ad hoc Organizations 

The use of ad hoc organizations to coordinate 
SE&I activities has proven to be a valuable tool. 
The effectiveness of SE&I depends heavily on 
good communications between organizations 
and the assurance that a common approach to 
the implementation of SE&I is being taken by 
all organizational elements. This is difficult to 
accomplish using the normal program office or- 
ganizations because they cannot directly ad- 
dress interorganizational communications and 
have difficulty in managing across organization- 
al lines. The ad hoc organizational structure, on 
the other hand, is made up of specialists from 
each of the affected organizations, and their ac- 
tivities directly promote interorganizational 
communications. Using this technique, techni- 
cal peers can plan and monitor the execution of 
specific SE&I activities. When a resolution can- 
not be reached within the ad hoc organizational 
structure, the issue is referred to the proper pro- 
gram management office. 

Common Organizational Structure Within 
the Program and Project Offices 

During the Apollo program, the program direc- 
tor decided to have all of the program manage- 
ment offices at both Level II and Level III adopt 
a standard organizational structure. Five offices 
reported to the program manager and to each 
project manager. This technique assured that 
the work breakdown structure was similar for 
all offices, that direct counterparts could be 
identified in each of the offices, and that budget 


allocations flowed down in a uniform and pre- 
dictable manner. All of these features resulted 
in less cross-linking between organizations and 
made the required program management activ- 
ity more rational and predictable. Although the 
specific office structure chosen would be differ- 
ent for each program, the concept of having uni- 
formity between the Level II and Level III man- 
agement offices should be considered for future 
programs. 

System Characterization Cycles 

Constructing the SE&I plan and identifying the 
required tasks is a very complex undertaking in 
large programs, and as previously described, it 
is best to meet the specified requirements. 
Analysis of the results reveals deficiencies and 
allows modifications to either the requirements 
or the system design to be identified, thus 
assuring an adequate margin of performance. 
Building on this core analysis cycle, it is 
relatively easy to plan the other SE&I tasks 
around it in a consistent manner, providing a 
complete characterization of the system capa- 
bility. 

Matrix Management Organizational 
Approach 

The concept of staffing the program 
management office with a small number of 
people who serve as managers only and then 
augmenting their capability with personnel 
drawn from other Center organizations in a 
matrix fashion has significant advantages. 
Personnel can be brought in from the 
organizations only when they are actually 
needed, and the makeup of the technical 
capability can be changed as a function of time 
to satisfy programmatic needs. The quantity can 
be augmented to meet program needs, i.e., major 
program reviews; the personnel involved can be 
assured of a career path in their parent 
organizations; and the individuals involved can 
continually replenish their expertise by partici- 
pating in the R&D activities in their parent 
organizations. 

This mode of operation has been quite successful 
and has demonstrated several additional 
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attributes such as reducing friction and unde- 
sired competition between the program office 
and Center functional organizations, improving 
technical communications across programs be- 
ing implemented simultaneously, and provid- 
ing an efficient way of phasing the development 
program into an operational role. It is notewor- 
thy that the assignment of program- level SE&I 
to a lead center, coupled with the execution of 
this assignment using Center functional organi- 
zations in a matrix fashion, allowed the program 
to take advantage of both the quality and quan- 
tity of technical expertise available throughout 
the Center. 

Use of a Prime Development Contractor 
to Provide SE&I Support 

In the Space Shuttle program, the SE&I support 
contractor was also the prime contractor for de- 
velopment of the Space Shuttle orbiter. Al- 
though there was considerable concern about 
the ability of the contractor to maintain objec- 
tivity in supporting SE&I, this concern was re- 
duced to an acceptable level by separating the 
direction channels of the development and inte- 
gration activity both within NASA and within 
the contractor’s organization. The support con- 
tract was also set up with an award fee structure 
in which SE&I was responsible for providing in- 
puts for the SE&I activities. There were many 
advantages to having this arrangement: 


a) The integration personnel were familiar 
with one of the major program elements 
and did not need to become familiar with 
that element or the general program 
structure. 

b) Expert technical specialists could be 
made available for both activities as 
needed. 

c) Many of the synthesis tools required by 
both activities were similar, and fre- 
quently one model could be used for both 
purposes with only minor modifications. 

d) Uniformity in approach assured ease of 
comparison of results from both project 
and program level activities. 


Summary 

The management of SE&I in NASA’s manned 
space programs has developed over the last 30 
years to integrate complex programs 
satisfactorily. Some of the approaches and 
techniques described in this paper may be 
helpful in integrating future programs. Careful 
consideration of the organizational structure 
and systems architecture at the start of the 
program will largely determine the level of 
effort required to accomplish the SE&I activity. 
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Shared Experiences from NASA 
Programs and Projects: 1975 

by Frank Hoban 


This paper summarizes the lessons learned from 
two workshops held at the National Academy of 
Sciences in 1975. The workshops were sponsored 
by NASA in conjunction with the National 
Academy of Engineering. Vince Johnson, former 
deputy administrator of the Office of Space Sci- 
ence and Applications, chaired the sessions. The 
National Academy of Engineering was repre- 
sented by retired NASA executives Robert Gil- 
ruth and Abe Silverstein, retired USAF General 
King, and Sid Metsger of COMSAT. 

The first workshop was held on February 24 and 
25, 1975. The second workshop was held on June 
3-4, 1975. Again, the National Academy of Sci- 
ences hosted the session. In order to provide more 
time for discussion, the number of projects to be 
covered was reduced from nine to six. 


Orbiting Solar Observatory 
Goddard Space Flight Center 
Robert Pickard, Manager 

The first project discussed was the Orbiting 
Solar Observatory-I (OSO-I). The OSO Project, 
dating back to 1959, consisted of a series of 
seven satellites prior to OSO-I. Ball Brothers 
had built all previous spacecraft; however, due 
to major changes, the I, J, and K spacecraft were 
competed, with the Hughes Aircraft Company 
the winner. 

The primary objective of the OSO-I mission was 
to investigate the lower corona of the sun, the 
chromosphere, and the interface in the ultravio- 
let spectral region, to better understand the 
transport of energy from the photosphere into 
the corona. The secondary objective was to study 
solar X-rays and Earth-Sun relationships and 
the background component of cosmic X-rays. 
OSO-I consisted of one mission, using a 2,340- 
pound spacecraft with a corresponding 


payload of 827 pounds, carrying eight experi- 
ments. Orbital altitude was to be 320 miles cir- 
cular at 33° inclination. Delta was the launch 
vehicle. 

Prior to OSO-7, the costs of all previous space- 
craft in the series were well below the $20 mil- 
lion level. OSO-7, the most expensive spacecraft 
of the series cost approximately $33 million; 
however, OSO-I costs were estimated at $58 mil- 
lion because of the complexity of the spacecraft 
and greater pointing accuracies. Spacecraft 
weights ranged from approximately 600 pounds 
for OSO 1-6 to 1098 pounds for OSO-7 and 2,340 
pounds for OSO-I. 

The project manager identified the following 
cost drivers: 

• Control system complexity and precision. 

• Stored command processor . 

• Development of special integrated circuits. 

• Inability of Government to maintain fun- 
ding when needed. 

• Experimenters building their hardware. 

Elements of cost control exercised by the project 
were: 

• Freezing the design. 

• Descoping. 

• Establishing cost ceilings on experiments 
and spacecraft. 

• Use of financial management reporting on 
major contracts. 
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• Weekly manpower tracking at spacecraft- 
contractor. 

• Frequent reviews with the contractor. 

Recommendations: 

(1) Use standard components and subsystems. 

(2) Build experimenters’ hardware to their 
specifications. 

(3) Establish adequate funding contingencies. 

(4) Freeze designs early and do not over- 
design. 

(5) Make subsystem engineers fully responsi- 
ble for cost, schedule, and performance. 


(6) Believe the cost model, not the proposal. 



Orbiting Solar Observatories advanced our 
understanding of the Sun’s structure and be- 
havior, thus indicating the physical processes 
by which the Sun influences the Earth. This 
early NASA project was directed by the Phys- 
ics and Astronomy program division. 


Small Astronomy Satellite Project 
Goddard Space Flight Center 

Marjorie Townsend, Manager 

The Small Astronomy Satellite (SAS) project 
consisted of three spacecraft: SAS-1, launched 
December 1970; SAS-2, launched November 
1972; and SAS-3, launched May 1975. The phi- 
losophy of the SAS program was to build a basic 
spacecraft and attach an experiment to it. The 
SAS-3 mission objective was to survey the celes- 
tial sphere for sources radiating in the X-ray, 
gamma-ray, ultraviolet, and other spectral re- 
gions, both inside and outside of our galaxy. The 
spacecraft weighed approximately 262 pounds 
with a 169-pound experiment package. The orbit 
was a 300-mile circular equatorial. The launch 
vehicle was a Scout. 

The main elements of SAS management were: 

• Management is not by committee — one 
leader makes final decisions. 

• Close teamwork by a small project team of 
high quality. 

• Conservative design concepts. 

• Control of workforce. 

• Parallel design on critical items. 

• Careful selection of parts and materials. 

• Good communications with contractors. 

• Selective testing program to minimize cost. 

• Ability to predict problems. 

• Good schedule control. 

Recommendations for future projects: 

(1) Start experiment development before 
spacecraft development. 

(2) Buy items requiring long lead times early. 
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(3) Implement configuration management 
after design phase; i.e., control changes. 

(4) Have good business people on the project to 
help control costs and predict overruns. 

(5) Work closely with contractor. 

(6) Use existing design where practicable, but 
don’t force-fit an old design. 



HEAO Experiment Package 
Goddard Space Flight Center 
Ronald Browning, Manager 

The next project discussed was the HEAO Ex- 
periment Package. The Marshall Space Flight 
Center (MSFC) was responsible for the manage- 
ment of the HEAO Project; however, the God- 
dard Space Flight Center (GSFC) provided two 
scientific experiments, a cosmic X-ray and a sol- 
id state spectrometer that were built in-house. 
The GSFC project office provided management 
of the hardware development and was the single 
point of contact with MSFC for all matters relat- 
ed to GSFC’s HEAO experiments. The goals for 
the project office were to accomplish the pro- 
gram on schedule and within cost, incorporating 
maximum hardware commonality between ex- 
periments, and eliminating unnecessary redun- 
dancies in the design of each experiment. 


Elements of management of the experiment 

package were: 

• Development of experiments consistent 
with established GSFC in-house mode and 
acceptable to MSFC. 

• Response to MSFC requirements. 

• Coordination of project requirements. 

• Configuration management. 

• Systems engineering and design. 

• Systems integration. 

• Systems tests. 

• Scheduling. 

• Financial planning and monitoring. 

Recommendations: 

(1) Establish necessary resources early to meet 
other Center requirements. 

(2) Thoroughly review experiments prior to 
Headquarters submission. 

(3) Have better defined statements of work and 
specifications. 

(4) Establish understanding at the begin-ning 
between Centers as to how the project will 
be managed and controlled. 

(5) Keep spacecraft development more in par- 
allel with experiment development, rather 
than one year behind. 


Air Density/Hawkeye Project 
Langley Research Center 

Claude Coffee, Manager 

The Hawkeye/Neutral Point Explorer Project 
was a 68-pound Scout-launched spacecraft built 
by the University of Iowa. The mission objec- 
tives were to study the topology of the magnetic 
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field at large radial distances over the Earth’s 
North Polar Cap and the interaction of the solar 
winds with the geomagnetic field. 

The University of Iowa was given total responsi- 
bility for project implementation with overall 
management responsibility at Langley. The uni- 
versity did an excellent job; the project came in 
ahead of schedule and under cost. Ball Brothers 
provided engineering support to the university. 
Unique features of this project included: 

• A one-year Phase B study effort prior to 
project approval. 

• An understanding with the university that 
funds were extremely tight, and overrun 
would not be funded by NASA. 

• The university’s use of contracted engineer- 
ing services in areas in which the universi- 
ty had no expertise, and to augment key 
project technical personnel. 

• Desire of principal investigators to launch 
at the optimum time (April through June). 

The Dual Air Density Explorer Project (DAD) 
consisted of two satellites to be launched into co- 
planar polar orbits by a single Scout launch ve- 
hicle. The two satellites were a .76mm diameter 
spun aluminum sphere and a 3.66m diameter 
aluminum/mylar inflatable sphere. Each sphere 
contained a mass spectrometer furnished by the 
University of Minnesota. 

The objective of the DAD mission was to study 
the vertical structure of the density, composi- 
tion, and temperatures of the upper atmosphere. 
The two spheres were the instruments for infer- 
ring the atmospheric density, while the mass 
spectrometers measured the atmospheric com- 
position. The molecular temperature was in- 
ferred by the change in vertical composition. 

Project cost drivers identified were: 

• Cost limitations resulted in an 11 -month 
slip in schedule. The greatest impact was 
in-house manpower, resulting in increased 
institutional management charges. 


• Institutional management system was 
Center-controlled with methodology chang- 
ing from year to year. 

• Project management must be critically 
aware of manpower loadings to hold down 
the institutional management changes. 

• Problem solving by increasing in-house 
manpower tends to impact total project 
costs. 

• Principal investigator did not establish 
firm cost estimates for data reduction and 
analysis. 

Problems encountered were: 

• Lack of early engineering support because 
of other in-house flight projects. 

• Viking problems that impacted project 
manpower at various times. 

• Inflation of sphere, coupled with the 
problems of procuring high-quality 
aluminum/mylar laminates materials for 
the inflatable satellite. 

Recommendations: 

(1) Extensive Phase B type studies should be 
performed for both the in-house and con- 
tracted effort. This means both manpower 
and funds availability. 

(2) Develop “baseline” design specifications 
and interfaces early. 

(3) Use fixed-price subcontracts. 

(4) Be cost conscious and impress this on con- 
tractors. 

(5) Avoid research and development after the 
project starts. 

(6) Establish a realistic schedule. 

(7) Develop a good relationship between 
project/contractor teams. 
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The Hawkeye Spacecraft is shown on the spin 
table during final systems tests before mating 
to the first five-stage version of the Scout rock- 
et. Hawkeye-1 was launched June 3, 1974 to 
investigate the interaction of the solar wind 
with the Earth’s magnetic field, with emphasis 
on the North Polar Cap. Hawkeye continued 
the University of Iowa’s Injun series, which 
provided a comprehensive study of charged 
particles trapped in the Earth’s magneto- 
sphere. 


Centaur Dl and Centaur 
Standard Shroud Projects 
Lewis Research Center 
Andrew Stofan, Manager 

The original Centaur stage was designed in the 
late 1950s and by the middle 1960s it needed up- 
dating. Several small study efforts were con- 
ducted in the 1966-69 time frame. An initial de- 
velopment contract was awarded to Convair in 
September 1969 to design, develop, manufacture 
and deliver one improved Centaur Dl upper- 
stage qualified vehicle. Included in the contract 
were special test equipment, a ground station at 
launch complex 36, tooling, and flight software. 
The basic negotiated contract was for $24 mil- 


lion with a period of performance from Septem- 
ber 1969 to April 1972. The contract, which in- 
cluded a cost-plus incentive fee/award fee, was 
unique for its time. 

The contract was later modified to provide a Dl 
Titan proof flight vehicle and a D1A vehicle for 
Pioneer-G. The total contract cost increased to 
$50 million. The total program was completed 
4.8 percent under cost, the end items were deliv- 
ered on schedule and the D1A vehicle met all ob- 
jectives. Although the D1T vehicle proof flight 
was terminated by a Centaur hydrogen boost 
pump failure, the validity of all the new develop- 
ments was demonstrated. 

The project manager detailed major project ele- 
ments in the development shop organization: 

• Simplified procedures and paperwork. 

Fewer formal documentation and reports 
(from 260 to 105). 

Segregation of program activities in con- 
trolled plant areas. 

Direct association of design engineers with 
fabrication, assembly, and test personnel. 

Simplified drawing system. 

Contractor program manager with overall 
responsibilities for technical, schedule, and 
financial aspects. 

Highly motivated government-contractor 
team with excellent communications. 

Government-contractor team uses identical 
controls: 

- Schedules by Statement of Work (SOW). 

- Financial data by SOW. 

- Technical requirements by SOW. 

Designation of contractor engineers for 
total SOW responsibility — technical, 
schedule, financial. 
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Other successful project management elements 
included: 

• Task definition thoroughly understood. 

• Cost definition based upon realistic goals 
with detailed backup rationale. 

• Motivating contract features. 

• Proper program management organization 
at NASA and contractor. 

• Appropriate management systems and 
tools. 

Studies of the Titan/Centaur launch vehicle 
indicated that a combined payload nose fairing 
and Centaur insulation system was desirable. 
Later studies defined the concept of the Centaur 
Standard shroud (CSS) to fulfill the study 
requirements. The Shroud was sized 
approximately 18.3m in length, 4.3m upper 
diameter and 3.35m lower diameter to 
accommodate the Viking payload and Centaur 
and Viking lengths. Requests for proposals were 
issued in July 1969. Lockheed Missiles and 
Space Company, Inc., was awarded the contract. 
Lockheed had extensive experience in building 
similar large shrouds for the Air Force and had 
a proven separation system. A cost-plus 
incentive fee/award fee contract was again used; 
however, this contract experienced a large cost 
overrun and cost growth. The major reasons for 
the growth were that the 4.3m constant 
diameter Lockheed design caused extensive 
Shroud/Centaur interface revisions and that the 
Viking Program slipped two years. The overrun 
was caused by contractor’s military shroud 
program development problems, the contractor 
scrapping the “development shop” approach, 
extensive personnel turnover in manufacturing, 
and overhead and labor rate increases due to 
reduced business volume. 

Technical results: 

• CSS passed all qualification tests success- 
fully and with relative ease. Only minor 
problems occurred with insulation and 
backup separation systems. 


• CSS performed flawlessly on proof flight 
and Helios-A launches. 

• All hardware was delivered on time and all 
major milestones were met. 

Recommendations: 

(1) Contract should not be started with major 
inadequacies in the work statements. 

(2) A “development shop” contractor organiza- 
tion is mandatory to control costs on con- 
tracts with a potential for engineering or 
schedule changes. 

(3) Contractor top-level management attention 
and authority are vital in controlling 
expenditures of contractor organizations 
not under direct control of the project office. 

(4) Defining sound interfaces between contrac- 
tors is often the critical factor in controlling 
overall project costs, and is worthy of the 
utmost attention of contractor and NASA 
upper management. 



An enhanced Centaur rocket with a resized 
shroud stands ready at Kennedy Space Center s 
complex 36 in 1978 to launch the Pioneer Venus 
Multiprobe, carrying four probes to enter the Ve- 
nusian atmosphere. 
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Mariner Mars 71 
Jet Propulsion Laboratory 

Robert Parks 

The final project discussed was Mariner Mars 71 
managed by the Jet Propulsion Laboratory 
(JPL). The Mariner Mars 71 spacecraft weighed 
2,266 pounds with an instrument package 
weight of 151 pounds. The primary mission 
objective was to study the dynamic charac- 
teristics and to provide broad area observations 
of the planet Mars from Martian orbit. 

The project was formulated in the face of a 
threat that no new planetary programs would be 
approved unless attractive low-cost systems 
could be provided. During this period, both the 
Mars 71 Probe and the Voyager projects had 
been canceled. 

A study of the Mariner Mars 71 launch 
opportunity revealed that it was the lowest 
energy year in the 15-year cycle and the Atlas 
Centaur could be used as the launch vehicle. 
The original approach was to use the Mariner 
Mars 69 science payload with no significant 
modifications. However, this approach was 
subsequently changed to include additional 
instrumentation, modifications to the Mariner 
Mars 69 instruments, and broader involvement 
of science investigators. These changes resulted 
in a cost increase from the initial estimate of $93 
million to $106.3 million. JPL managed the 
project in the subsystem contracting mode. 

Summary of major cost drivers: 

• Inflation. 

• Mission scope changes: 

- Science experiments. 

- Adaptive mode for mission operations. 

- Science data analysis expansion. 


Experience with handling cost drivers: 

• Inflation — per direction, initial cost 
estimate stated in 1968 dollars with no 
allowance for inflation. 

• Unanticipated technical problems. 

• Scope changes — additional science instru- 
mentation. 

• Costs partially offset by deleting third 
spacecraft. 

Recommendations: 

(1) Initial cost estimates should include an al- 
lowance for inflation. 

(2) A definitive statement of science payload 
requirements, with an estimate of instru- 
ment development costs and their effects on 
spacecraft costs, is needed. 

(3) Include some funding contingency to cover 
costs of unforeseeable problems. 

(4) Standardize, wherever practical, on de- 
signs, components, and test procedures. 

(5) Undertake block buys of identical hard- 
ware subsystems. 


(6) Share mission operations costs associated 
with personnel and software. 
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Shared Experiences from NASA Programs & Projects 


Summary 

These programs and projects — ranging in cost 
from $1 million to $2.5 billion— show not only 
the vast diversity of NASA activities but also 
the wide differences of opinion and strong, inde- 
pendent thinking on the part of NASA program 
and project managers. No two sets of cost drivers 
or sets of recommendations are identical, but a 
pattern does emerge. That pattern can best be 
summed up in one word: planning. Good plans 
make good projects. And good planning starts 
with the selection of well-trained, competent 
program and project management leaders and 
teams. 

All too often, especially in the early days, 
program managers learned on the job. Ex- 
perience is a good teacher, but there are other 
ways to learn. There is no logical reason why we 
must learn only from our mistakes when we can 
learn from the mistakes — as well as successes — 
of others. In this article, we have lists and lists 
of reminders and suggestions from program and 
project managers, many of whom have gone on 
to lead bigger programs within the agency and 
in industry. Their wisdom is valued and can be 
worked into the curriculum of any upcoming 
NASA project or program managers. Comparing 
and contrasting methods and techniques in the 
lists shows that while there is no one way to 
plan a program and manage it, some ways may 
be certainly better than others, and some are 
lessons learned, never to be repeated. 

The following recommendations were made to 
the Deputy Administrator upon completion of 
the workshops: 


• Initiate training for project personnel 

• Hold periodic meetings with project person- 
nel 

• Prepare “lessons learned” reports at the 
completion of projects 

• Establish independent cost review teams to 
verify estimated projects costs 

• Establish an agency-wide piece parts pur- 
chase and qualification program 

• Conduct a definitive reliability study 

• Establish a policy regarding research and 
development in flight projects versus “en- 
abling technology” under SR&T 

• Initiate pre-project approval buys and block 
buys 

• Establish and manage funding contingen- 
cies 

• Consider cost-at-completion versus cost- 
per-FY for total cost management 

• Define Headquarters role in project man- 
agement 

It is interesting to note that only the first 
recommendation was fully implemented and 
even it failed for a time. The other 
recommendations were well thought out and 
made excellent sense but there were no sponsors 
to carry them out. 
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A Strategy of Cost Control for 
Mariner Venus/Mercury ’73 

by John R. Biggs and Walter J. Downhower 


The spacecraft NASA launched on November 3, 
1973 to explore Venus and Mercury proved a 
notable success both in space and on the ground, 
as a development project. This article on the 
development points out management 
approaches and techniques that kept schedules 
and controlled costs, the intent being to 
stimulate thought about how to do the same 
with future spacecraft and payloads. 

The Mariner Venus/Mercury ’73 (MVM ’73) 
project kept within its originally established 
goals for schedule, performance, and cost. 
Underlying this development success was the 
availability of the Mariner technology. But 
meeting the goals demanded management 
determination, planning, and discipline to make 
optimum use of state-of-the-art technology — on 
the part of people at NASA, JPL, and The 
Boeing Co. (the main contractor). 

Pre-project Highlights 

The earliest studies of the concept and scientific 
potential of a Venus/Mercury swing-by mission 
drew many to observe it could be the unique 
mission of the decade. It was the first to use a 
gravity-assist technique — taking advantage of 
an unusual planetary configuration existing in 
1973. Using the gravitational field of Venus, it 
was possible to swing an Atlas-Centaur- 
launched spacecraft onto a flight path to 
Mercury. Exploration of Mercury otherwise 
would not have been possible without employing 
a much larger launch vehicle. 

The 1968 Planetary Exploration Summer Study 
conducted by the National Academy of Sciences 
(NAS) Space Science Board (SSB) endorsed this 
mission. The SSB suggested that the mission be 
planned around a single launch to make best use 
of the science funds available to NASA. 


Mission Objectives 

The following mission objective, established by 
NASA following the Summer Study in 1968, did 
not change during the program’s several years 
of design and development: 

Primary. During the 1973 opportunity, to 
conduct exploratory investigations of the 
planet Mercury’s environment, atmosphere, 
surface, and body characteristics and to ob- 
tain environmental and atmospheric data 
from Venus during the flyby. First priority 
goes to Mercury investigations. 

Secondary. To perform interplanetary ex- 
periments while the spacecraft flies from 
Earth to Mercury, and to obtain experience 
with a gravity-assist mission. 

JPL had long experience with planetary pro- 
grams, but the opportunity for other Centers to 
participate in the program was not foreclosed. 
NASA’s Goddard Space Flight Center (GSFC) 
had plans for a Planetary Explorer spacecraft 
potentially able to do the mission and its ap- 
proach was sufficiently attractive to invite fur- 
ther study. During the remainder of 1968 and 
1969, both GSFC and JPL studied their respec- 
tive concepts; this early competition contributed 
to thoroughness of the early planning effort. 

The Scientists 

An innovative technique was used on MVM ’73 
to assure early involvement of the scientific 
community with mission definition and prelimi- 
nary design. In past missions, no effective 
mechanism for the early detailed planning in- 
volvement of outside scientists had evolved, and 
selection of principal investigators had been 
withheld until the completion of mission-profile 
studies and early system determinations. By the 
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time the investigators were selected in those 
programs, many design features had already 
been established. 

For MVM ’73, selected scientists were invited to 
participate in the early mission planning. A 
group of scientists representing the several dis- 
ciplines to be involved in the science payload 
was selected and formed into a Science Steering 
Group (SSG) in September 1969. The scientists 
influenced the early mission and spacecraft de- 
sign, holding to a minimum conflict between 
mission constraints and science needs. 

Based on the positive results from these 
planning efforts, MVM ’73 was presented in the 
FY70 NASA budget as an Office of Space 
Science and Applications (OSSA) “new start” at 
a funding level of $3 million. An Authorization 
Conference Committee approved the project for 
inclusion in the FY70 authorization action, and 
funds were appropriated as requested. The 
scientific principal investigators were then 
selected in a normal fashion after project 
authorization. 

Robert S. Kraemer, then head of planetary plan- 
ning at NASA, pressed innovation in the early 
planning of MVM ’73. Kraemer later moved to 
the post of planetary program director, with re- 
sponsibility for implementing the project. 

The “Low-cost” Attitude 

The “low-cost” attitude, so evident in the 
management of MVM ’73, developed early. The 
study teams were instructed to consider 
maximum use of established designs, residual 
hardware, and existing capabilities. Very strict 
financial constraints were factored into payload 
planning. The SSG was requested to consider 
minimum-cost experiments that would yield 
acceptable scientific data. The potential 
experiment proposers were advised to use 
existing designs for science instruments, to use 
flight-tested experiments wherever possible, 
and to consider modifications only for high- 
payoff options. They were also to limit quality 
assurance, reliability, and documentation 
requirements to that previously applied to prior 
successful similar instruments. 


GSFC and JPL established the mission and 
spacecraft baseline, developed preliminary 
implementation plans incorporating the 
experiment approach being followed by the SSG, 
and made early cost estimates. JPL called on its 
extensive experience with Mariner spacecraft. 
Goddard proposed a spin-stabilized spacecraft of 
the Explorer class. 

JPL proposed to commit to a fixed cost to do the 
MVM ’73 mission in the system-contract mode. 
W.H. Pickering, JPL director, advised OSSA in 
December 1969 that JPL could and would un- 
dertake the project for a cost not to exceed $98 
million. 

The JPL Goal 

After a full briefing on the approaches by GSFC 
and JPL (proposed science return, spacecraft 
configurations, management modes, manpower 
and cost projections), OSSA chose JPL. In a 
letter to Dr. Pickering, assigning project 
management to JPL, John E. Naugle, Associate 
Administrator for Space Science, made this 
comment regarding mission cost: “A major 

concern has been and remains to be the total 
runout cost of the project. I am sure you are 
aware of the cost history for which estimates 
have ranged from approximately $70 million to 
well over $100 million. It is mandatory that the 
project be accomplished for a total cost not 
exceeding the $98 million quoted in your letter 
and strong efforts should be taken to reduce this 
figure.” This letter set the fundamental cost 
understanding between OSSA and JPL. 

The “Work Package” Concept 

JPL expertise in conducting flight projects 
predominantly involved obtaining spacecraft 
subsystems from industry thorough the JPL 
technical divisions with JPL accomplishing the 
spacecraft systems functions. The major 
challenge faced by JPL in the MVM ’73 project 
was to utilize and adapt the fundamental JPL 
strengths to a system-contracting mode. 

A JPL team suggested a “work package” concept 
as the best means to transition from the use of 
subsystem contractors to a systems contractor. 
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Appropriate elements of the JPL matrix organi- 
zation prepared the work packages. 

The Project Office exercised system technical di- 
rection, but the detailed definition, monitoring, 
and control of individual work units was per- 
formed by the appropriate JPL organizational 
element under the overall coordination of the 
JPL Project Office. 

JPL also determined other factors important to 
implementing the project. It selected a cost 
contract with award fee. A specific JPL 
procurement group co-located with the Project 
Office would administer the system contract and 
other MVM ’73-related ones. It was decided that 
the JPL in-house tasks should be given as much 
visibility and control as those of the system 
contractor. The constraint on resources dictated 
that all elements of the project, regardless of the 
performing organization, be monitored in the 
same detail, and the risks balanced across all 
portions of the project’s activities. 

PAD, Procedures and Payoff 

The NASA project-approval process entails a 
basic contract or understanding between the 
Administrator and the responsible Program 
Associate Administrator: the Program 

Authorization Document (PAD). The initial 
PAD for the MVM ’73 project was signed on 
February 27, 1970. The objectives, technical 
plan, major support interfaces, and procurement 
approach discussed in that PAD remained 
unchanged throughout the development. 

The JPL approach strongly exercised the 
Mariner heritage. MVM ’73 benefited not only 
from Mariner design derivation but also from 
residual hardware from past programs. The plan 
emphasized maximum use of existing designs, 
hardware and software. This approach saved 
perhaps 50 percent of design and development 
costs and perhaps 15 percent in hardware 
costs — a big payoff. 

The Cutting Edge 

The project team had lengthy discussions with 
JPL implementing organizations to identify the 


optimum way to meet cost constraints. Control 
of cost-at-completion became a basic concept 
stressed by both the JPL and Headquarters 
offices in an attempt to avoid the less-efficient, 
year-by-year funding controls often followed in 
projects. The MVM ’73 project made it clear that 
each assigned work unit was the total 
responsibility of the cognizant division and that 
responsibility for determining the least costly 
way to do the work rested squarely with the 
division. For each potential increase in cost, 
something had to be cut back. The JPL divisions 
almost invariably proposed specific cuts 
concurrent with notification to the project office 
of potential cost increases. 

Schedule Strategy 

The schedule adopted for MVM ’73 provided an 
unusually long period for advanced planning 
and deferred this start of major contracts. This 
approach, unprecedented in launch-critical 
planetary programs, may have been the single 
most important factor in meeting cost goals. 

The added risk to the mission was offset by the 
increase in design time and better planning of 
the fabrication effort. The effect was to establish 
a “most cost-effective” approach. The greatest 
number of people worked on the project for the 
shortest period of time. (Axiom: the shorter the 
schedule, the less the cost.) 

Once adopted as a project philosophy, delay in 
implementation was applied to all aspects of the 
project. The systems contract was delayed three 
months beyond the schedule considered minimal 
by many. Other subcontract work was released 
on a schedule that limited the work time to a 
prudent minimum. A “single thread” approach 
was followed in the spacecraft design where 
options were studied, one was adopted, and the 
work started without carrying parallel efforts. 
Mission operations work was held off beyond the 
schedule previously considered to be optimum. 
Flight operations crew training was held off as 
long as possible. And it worked! There were no 
major schedule slippages, no seriously late 
deliveries of equipment, and no extraordinary 
work-arounds. 
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“Do Only the Essential” 

“Do Only the Essential” became a discipline 
among project participants. To challenge the 
need for each operation, each added procedure, 
each piece of special equipment, and each 
separate design, redundant feature or test 
became routine. If a function, part, or operation 
was determined to be needed, then the search 
went on to see if hardware was available from 
other projects, or if the process had been 
developed by someone else. If the part or process 
was not available, then there was an attempt to 
use available designs. 

This discipline was not only applied by the JPL 
managers but by Boeing as well. The Boeing 
spacecraft program manager proved extremely 
resourceful in identifying short-cuts, reductions 
in paperwork, and unnecessary redundancy — 
the cost-type contract not withstanding. The list 
of hardware and effort saved through this effort 
is too lengthy to discuss here, but the savings ex- 
tended to every area of the project effort. 

One unusual saving is notable. The project team 
encouraged a local college, assisted by several 
other colleges and high schools, to produce the 
spacecraft models, which often cost more than 
$100,000. The project gained all the models re- 
quired, the students and schools gained good ex- 
perience from their work on an interesting task, 
and NASA saved dollars and encouraged local 
community interest and support. 

Project Team 

The most important ingredients to project 
success were the attitudes and skills of the 
people assigned to manage it. JPL’s experience 
in dealing with a system contractor was limited 
to Surveyor, and by 1970 relatively few JPL 
people had been involved in the early stages of 
that project. The person most familiar with its 
operations was Walker E. “Gene” Giberson, who 
had been Surveyor’s project manager. He was 
appointed MVM ’73 project manager in January 
1970. 

Giberson assembled a small team of individuals, 
each selected on the basis of his past project 


experience and his willingness to work within 
firm budget allocations. The key members of 
this team included V.C. Clarke, Jr., mission 
analysis and engineering manager; J.A. Dunne, 
project scientist; J.R. Casani, spacecraft system 
manager; J.N. Wilson, assistant spacecraft 
system manager and N. Sirri, mission operation 
system manager, This team, trim in size yet 
representing broad experience, represented the 
core of MVM ’73 project management. 

The Guidelines 

At first, the team spent considerable time 
developing the project’s operating concepts and 
indoctrinating everyone involved with the 
organizational and project philosophy. They set 
and held to the following guidelines throughout 
the project: 

• Establish early project guidelines, objectives 
and constraints 

• Use a small staff for planning 

• Prepare detailed plans and tasks before 
initiating a contract: 

- Specific and detailed RFPs 

- A careful tradeoff assessment between 
JPL and contractor furnished equipment 

- Use of existing documents, reports, and 
systems 

- Careful selection of fee approach 

• Establish cost-at-completion planning, 
budgeting and emphasis 

• Secure all contracts before starting work 

• Keep work and budget plans up-to-date 

• Exercise organizational impedance 
matching and communications 

• Maximize technical interaction 

• Use the concept of cognizant work unit 
engineer 

• Hold frequent face-to-face meetings of 
operating managers 

• Identify and resolve problems promptly 

• Make periodic status and performance 
reviews 

• Indoctrinate all involved with cost goals 

- Instill cost consciousness 

- Make cost goals believable 

- Develop a clear understanding of the 
cost-control system 
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• Bring manpower onto the project and move 
it off in a timely manner 

The Hot Seat 

The Headquarters Program Office/Center 
Project Office interface can be extremely critical 
to the success of a project. If the program mana- 
ger and project manager have differing am- 
bitions and objectives or, as occurred in some 
instances, an adversarial relationship, the 
project can suffer. N. William Cunningham, the 
Headquarters program manager, and Gene 
Giberson, the JPL project manager, enjoyed an 
open and forthright relationship, a cornerstone 
of a sound management structure. 

The person on the “hot seat” for cost 
management is, however, the project manager. 
The project manager is the one most responsible 
for establishing the attitude and the framework 
for the daily tradeoffs of cost, performance, and 
schedule where it is most essential to maintain a 
proper perspective. Without his cost conscious- 
ness, his basic approach to costs, MVM ’73 would 
not have enjoyed it obvious cost success. This 
cost attitude is the more unusual since NASA 
had previously stressed technical performance 
and schedule requirements over cost as a 
discipline. 

The Science Steering Group selected in Septem- 
ber 1969 held its final meeting in March 1970. 
In its report, the SSG recommended a minimum 
science payload composed of a plasma science 
experiment, a magnetometer, an infrared radi- 
ometer, an ultraviolet spectrometer, a television 
system, and an energetic particles experiment. 

One of the tasks of SSG was to make a detailed 
cost estimate for each potential experiment — 
including design, development and fabrication 
costs of the hardware, cost of personnel support 
for launch and mission operations, and cost of 
data analysis and interpretation and 
publication of results. These cost estimates, plus 
a project estimate for integrating the 
instruments into the spacecraft, shaped the first 
science budget for the project at $13 million. 

An Announcement of Flight Opportunity (AFO) 


issued in March 1970 invited proposals for ex- 
periments. It stressed the intent to select only 
proven flight-qualified instruments. The AFO 
also stressed the desire to minimize documenta- 
tion and stated the intent of JPL to monitor de- 
velopment of the instruments only at the inter- 
face level. 

Forty-six proposals were received and evaluat- 
ed. After ranking them in terms of science excel- 
lence, technical and engineering requirements, 
cost and system integration, the program office 
recommended seven payloads to the OSSA Asso- 
ciate Administrator. The payload cost estimates 
went as follows (in millions of dollars): 


Television 

$6.226M 

Radio science 

0.500 

Ultraviolet 

0.575 

Infrared 

0.928 

Magnetometer 

0.688 

Energetic particles 

0.383 

Plasma science 

0.945 

Total 

$10,245 

Instrument integration 

2.355 

Total 

$12,600 


To each of the principal investigators selected, 
Dr. Naugle addressed this comment: “I must 
emphasize, once again, that the total negotiated 
figure (dollar cost as selected) cannot be 
exceeded. Accordingly, I have instructed the 
JPL Project Office that in the event of an 
anticipated cost overrun, their alternatives will 
consist of helping you to reduce the scope of your 
experiment, or recommending its termination.” 

Science and Dollars 

Whereas most past selections had been consid- 
ered final at the time of announcement, the let- 
ter from Dr. Naugle clearly pointed out that the 
selection was to be considered tentative until 
the investigators and JPL completed negotia- 
tions. A process of fact-finding and negotiation 
between JPL and each of the scientific investi- 
gators followed, which resulted in well-defined 
relationships before the major development ef- 
fort commenced. 

It was made clear in the selection and negotia- 
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tion process that the principal investigator was 
responsible for the implementation and develop- 
ment of the investigation, including the instru- 
ment. The project office followed through on the 
intent to control principally at the instru- 
ment/spacecraft interface level. The systems 
contractor was responsible for integration of the 
instruments into the spacecraft. 

One innovative technique required the systems 
contractor to “sign off” on changes to experiment 
interface drawings, although the contracts for 
the experiments were between JPL and the in- 
vestigator. This technique provided greater as- 
surance that the systems contractor was aware 
of the latest configuration of the experiment 
hardware, and helped avoid surprises at the 
time of integration. 

Dr. Naugle views MVM ’73 as the most success- 
ful development of scientific instruments within 
tight cost constraints. The addition of the ex- 
periment integration costs to delivered cost 
brings the total for science very close to but 
within the original budget of $13 million. 

Meeting payload cost goals begs the question 
whether controls compromised the science in- 
vestigations. A detailed review of the develop- 
ment history of each instrument clearly demon- 
strated that not only was there no compromise of 
the investigations during development, but that 
significant capability was added to several in- 
vestigations. Any science compromise on MVM 
’73 reflects directly the original constraints es- 
tablished before experiments were selected. The 
decisions to tightly constrain payload costs, to 
fly only proven instruments, and to apply go/no- 
go cost restrictions on instrument development 
are serious policy decisions to be carefully 
weighed and considered. They cannot be applied 
to every payload but they paid off in MVM ’73. 

NASA and JPL held an industry briefing in Feb- 
ruary 1970 to apprise companies of the goals and 
constraints of the MVM ’73, to provide detailed 
technical and program information for early 
planning, to encourage competition, and to en- 
list industry’s help in determining an optimum 
role for a system contractor. Forty-one firms at- 
tended the briefing. 


JPL asked the companies for suggestions re- 
garding implementation of the systems contract 
approach; separate day-long meetings were held 
with the most interested competitors to discuss 
their suggestions. During these meetings, the 
companies made recommendations on contract 
scope, roles and relationships, Mariner technol- 
ogy transfer, contract type, GFP handling and 
other areas they believed were important to the 
success of the effort. 

A procurement plan evolved in which the sys- 
tems contractor would have the major role (1) to 
design, fabricate, assemble, and test one flight 
spacecraft, one test spacecraft, associated test 
models, test and support equipment and appro- 
priate spares; and (2) to provide level-of-effort 
support to JPL in mission analysis and engi- 
neering, JPL subsystems activities, and mission 
operations. 

RFP Features 

The JPL project definition effort had been pro- 
ceeding for a year at the time the Request for 
Proposals (RFP) was issued. The result of that 
effort was a very detailed, explicit RFP. It was 
an extensive compendium explaining project ob- 
jectives, project organization and implementa- 
tion, schedule, project control dates and docu- 
ments, work breakdown structure, spacecraft 
design summary, scope of contract, general de- 
scription of work, JPL/contractor relationships, 
and mission operations. Its most unusual fea- 
tures included these: 

• A spacecraft systems specification which 
attempted to state only minimum 
requirements. 

• The predetermined intent to divide all work 
into discreet work units (which allowed 
separation of responsibilities and facilitated 
work description, understanding, 
negotiation, and JPL monitoring). The 
definition of each work unit was written in a 
standard format. 

• The request for firms to propose overhead 
cost ceilings. 

• The request for baseline and alternate cost 
proposals to get the best cost mix between 
JPL and contractor-furnished equipment. 
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• A call for incentive proposals which gave 
heavy emphasis to cost, but also 
statedstrong preference to award fee. 

• Emphasis on minimum documentation and 
maximum use of procedures, forms, 
techniques, etc., that the contractor 
currently used. 

• Detailed documentation covering Mariner 
’69 hardware, Mariner ’71 hardware, and 
other JPL-furnished equipment, along with 
drawings, schematics, processes and 
procedures to assure full use of the Mariner 
heritage and facilitate cost estimates. 

Four proposals were received. The Source Eval- 
uation Board presentation was made to the 
NASA Administrator on April 28, 1971, and The 
Boeing Co. was selected as the systems contrac- 
tor. 

Holding Out for a Firm Negotiated Contract 

The pressure to award the contract and 
commence work was very strong following the 
April selection, but the project manager and 
contract manager held out for a firm negotiated 
contract before allowing work to be started. 
Within six-and-one-half weeks after selection, 
the negotiations were completed and a definitive 
contract was awarded. Work started on June 17, 
1971. 

The contract, a cost-plus-award-fee type, empha- 
sized the contractor’s complete responsibility to 
meet the spacecraft system performance re- 
quirements. The contract effort was divided into 
work units, each assigned to a manager within 
The Boeing Co. The work units included in the 
contract were compatible with both JPL’s tech- 
nical division organization and Boeing’s project 
structure. 


Controlling Overhead 

A serious concern in systems contracting had 
been the inability to predict overhead costs. The 
parties agreed that a ceiling on overhead costs 
would be negotiated into the contract. Such ceil- 
ings on overhead are unusual in normal circum- 
stances, and all the more so in this case, consid- 
ering the depressed economic situation The Boe- 
ing Co. faced in the spring of 1971. The ceiling 
on overhead never was invoked because Boeing 
actually underran the negotiated overhead cost. 

There were strong cost incentives negotiated 
into the contract and a process for evaluation 
and award was developed with emphasis on 
performance and cost control. The award fee 
provisions and the system employed to carry 
them out appear to have been effective in 
contributing to the contractor’s performance. 
Benefits included these: 

• Boeing’s spacecraft program manager had 
the opportunity to increase the fee 
significantly. The award fee structure 
allowed broad latitude in the approach to 
cost and performance tradeoffs. 

• The process enforced periodic, results- 
oriented evaluations and communications at 
all levels. The process and the resultant 
dialogue tended to remove the obstacles that 
stand in the way of the natural motivation to 
do a good job. By clarifying goals, 
establishing emphasis, eliminating 
misunderstandings, and highlighting 
problem areas for mutual attention, 
obstacles were removed or reduced. 

• Attention of the contractor’s top 
management was obtained by the formal 
feedback process (briefings supported by 
letters). 




CY 1971 


CY1972 

Category of 

Negotiated Per 

Negotiated Per 

Indirect Expense 

Contract Actual 

Contract Actual 

Engineering 

$3.94 

$3.74 

$4.14 

$3.88M 

Manufacturing 

4.99 

5.08 

5.24 

4.97 

Productive Material 

10.5% 

7.9% 

10.5% 

6.7% 

Subcontract Material 

6.1% 

5.5% 

6.1% 

3.6% 

Area Administration 

15.1% 

14.35% 

15.1% 

11.9% 

Group Administration (remote) 

9.6% 

9.75% 

9.6% 

7.8% 
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• The discipline of the award fee evaluation 
process improved JPL’s internal 
communications at all levels, including top 
management on the award fee review board. 

Tight Control 

JPL has a reputation in the industry for aggres- 
sive contract management, often expressed as 
complaints of “too tight control” by subcontrac- 
tors. But the JPL system proves effective in as- 
suring performance. 

In MVM ’73, change orders were kept to a mini- 
mum throughout the contract and were negoti- 
ated into the contract promptly after issuance. 
Project office personnel monitored Boeing’s 
work very closely. The work unit breakdown 
made it possible for cognizant JPL engineers to 
thoroughly understand the job, follow its 
progress in detail, and identify potential prob- 
lems early. 

Early identification of problems coupled with 
open, candid discussions among The Boeing Co. 
and JPL managers were basic contributors to 
the success of the project. D.T. Gant, contracts 
manager, L.V. Burden, financial manager, and 
L.M. Bates, cost analyst, who were collocated in 
the project office, effectively kept the project 
managers alert to unexpected deviations. 

The NASA Management Audit Office, not noted 
for its approbative descriptions of NASA oper- 
ations, gave this appraisal: “In our opinion, the 
JPL surveillance of the contract, its assignment 
of capable and motivated personnel to monitor 
the performance of MVM ’73 on a full-time ba- 
sis, and the apparent stringent cost controls im- 
plemented by The Boeing Co. before contract 
award, and retained throughout the program, 
contributed to Boeing’s successful cost perfor- 
mance under MVM ’73.” 

Good Communications 

Stressed by the managers, good communications 
led to early anticipation and resolution of issues 
and the timely availability of data for decision 
making. Some of the techniques used to assure 
good communications included: 


• A weekly “Agreement/Disagreement Log,” 
maintained by work unit personnel and 
reviewed by the JPL spacecraft system 
manager and The Boeing Co. spacecraft 
program manager. 

• Weekly face-to-face meetings between the 
systems contractor, systems manager and 
the systems contractor program manager. 

• A weekly summary of agreements and 
formal tracking of action items. 

• Daily meetings between The Boeing Co. test 
and operations representatives and the JPL 
resident staff during the system test period. 

• Weekly “Problem TWX.” 

• Formal monthly progress reviews to give an 
overview and detailed status and plans with 
particular emphasis on problems. 

• Easy access to The Boeing Co. and JPL top 
management (above the level of project 
personnel). 

• Attendance at award fee briefings by 
Boeing’s top management. 

• An extensive and definitive award fee letter 
and briefing, held not later than 15 days 
after the end of each period. 

• Rapid escalation of significant problems to 
the appropriate management level for 
resolution. 

None of these actions should surprise good man- 
agers, but taken together, they may not be com- 
monplace. These combined techniques greatly 
helped the MVM ’73 project meet its goals. 

Highlights of Contractor Performance 

The Boeing Co. faced an uncertain general busi- 
ness position at the time the MVM ’73 project 
contract was issued. Major reductions had been 
made in Boeing’s commercial airplane oper- 
ations, and significant reductions in employ- 
ment had been made at Boeing Aerospace Co. 

Despite the drastic reduction in backlog and di- 
rect workload, Boeing was able to reduce over- 
head costs and even underrun the overhead pro- 
jections on the MVM ’73. The aerospace industry 
and its government customers are conditioned to 
the increase of overhead runs when the direct 
base decreases. This “fact” is considered by 
many to be axiomatic and inviolate— overhead 
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costs regarded as “fixed” or unalterable and nec- 
essary to support the base for doing business. 
The example of Boeing’s experience in 1970 and 
1971 could be a good case study in ways to re- 
duce overhead expense as the direct base de- 
creases. 

E. Czamechi served as The Beoing Co. MVM 
spacecraft program manager from the early pro- 
posal phases in 1970 through early 1973. H. 
Kennett served as deputy program manager and 
succeeded Czarnechi. Their participation contri- 
buted immensely to the success of MVM ’73. 
They have reviewed their experience, and un- 
derscored these management concepts and tech- 
niques employed on MVM ’73: 

• Spacecraft requirements must be defined 
clearly and early. 

• Match people (skills) to work unit tasks. 

• Use the “cognizant work unit engineer” 
concept 

• Select the baseline configuration early. 

• Implement a system of program reviews and 
reporting with joint chairmanship by 
contractor and customer. 

• Define and assess technical performance, 
schedule, and cost risks, and develop work 
around plans. 

• Educate key personnel in the company’s 
cost-accounting system so that when 
tradeoffs and decisions are to be made, all 
factors are properly considered and their 
true impact on cost understood. 

• Shorten and improve communications 
through collocation and program 
organization 

• Establish organizational relationships (e.g. , 
JPL/Boeing) and communication channels 
early. 

• Motivate people through performance 
assessment, promotion, compensation, and 


achievement awards. 

• Emphasize cost trades during design phase. 

• Ensure that only essential work is 
accomplished. 

• Use an objective performance measurement 
system. 

• Rely on each cognizant work unit engineer 
for early identification, reporting and, when 
feasible, problem resolution. 

• Use dedicated manufacturing and test 
facilities. 

• On-load and off-load manpower in a timely 
fashion. 

• Use recovery (“tiger”) teams to work 
problems. Teams of specialists from outside 
the program can be assigned problems and 
provide instant expertise without a 
continued expense to the program. 

A Postscript 

The MVM ’73 spacecraft (Mariner 10) was 
launched on November 3, 1973. A number of 
problems developed early in the flight, but none 
degraded the mission and none was the obvious 
result of actions taken to control cost. The 
spacecraft reached Venus on February 5, 1974, 
and returned a full set of scientific data, 
including more than 4,000 pictures. The 
gravitational attraction of Venus altered the 
spacecraft’s flight path as planned, swinging it 
toward Mercury. The spacecraft passed within 
500 miles of Mercury’s surface on March 29, 
1974, and returned the first close scientific 
observations and pictures of the planet. 

The project is currently [1974] anticipating a 
modest underrun at completion. So MVM ’73 
more than met its original performance objec- 
tives and, in addition, served to work out man- 
agement approaches and techniques to control 
costs. 
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Science Cost History 


Experiment 

Appointment 
Letter Cost/ 
OSE a) 

Original 
Negotiated Cost 
(March 30. 1971) 

Estimated 
Cost-at-Completion 
$<October 31. 1973) 

±Cost-at- 

Comnletion 

Infrared 

Radiometer 

$ 789,000/ 

21,000 

$ 759,000 

$ 

726,000 

- $84,000 

Plasma 

Science 

945,000/ 

75,000 

1,020,000 


1,020,000 

0 

Charged 

Particle 

Telescope 

383,000/ 

8,000 

391,000 


505,000 

+ 114,000 

Magnetic 

Field 

685,000/ 

25,000 

710,000 


671,000 

- 39,000 

Ultraviolet 

Spectrometer 

575,000/ 

24,000 

575,000 1 (2) 3 


705,000 

+ 106,000 

Television 

Science 

475,000/— 

475,000 


555,000 

+ 80.000' 3 ’ 

Radio Science 
and Celestial 
Mechanics 

500,000/— 

500,000 


500,000 

0 

TV System 

4.505.000 

5.751.000 

4.430.000 

5.765.000 


4.682.000 

5.787.000 

+ 177,000 
+ 36,000 

TOTAL 

$ 10,256,000 

$ 10,195,000 

$ 

10,469,000 

+ $213,000 


(1) OSE-Operational Support 

(2) Did not Include Bench Checkout Equipment (BCE) 

(3) Raw Mosiac Costs-Change In Scope 
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The Shuttle: 

A Balancing of Design and Politics 

by Dale D. Myers 


When Apollo was started, and even deep into the 
program, NASA had very little integrated 
planning. No one tried to balance efforts 
between aeronautics and space, or even manned 
versus unmanned activities. Jim Webb seemed 
to want to keep his options open until the last 
minute, and a long range plan would be a 
deterrent to that idea. Planning groups were set 
up, but no lasting results emerged. Even the 
planning of the science experiments for Apollo, 
worked almost entirely between Manned Space 
Flight and the Office of Space Science and 
Applications, was late getting into the system. 
When it came to real post- Apollo planning, even 
though there were pockets of studies and 
interest, no overall plan emerged until 1969. 
Detailed specifications from the Congress and 
their staffs were not a major problem. Congress 
would want to be kept informed about our 
planning (no surprises) but in general, their role 
was supportive. 

In 1969, the Space Council, under Vice Presi- 
dent Agnew, ran a post-Apollo study, with most 
of the inputs coming from NASA through Dr. 
Tom Paine, who, as Deputy Administrator, was 
a member of the task force. Dr. George Mueller, 
then Associate Administrator for Manned Space 
Flight, made some strong inputs to the study. 
NASA’s budget had peaked in 1966, but ex- 
trapolations based on the strong support of the 
public led to a very ambitious outlook. As usual, 
NASA saw the budget reduction as a temporary 
thing, failing to understand the growing Viet- 
nam budget, and leaders of the Congress and the 
administration increasingly fearing a failure in 
space. 

The results of the post-Apollo study were: 

• First, we must reduce the cost per pound to 
orbit by a factor of ten. This would be done 
with a reusable launch vehicle. 


• A reusable Space Tug was needed to reduce 
the costs from low Earth orbit to geostation- 
ary orbit. 

• We must have a large, Saturn V-launched 
space station. 

• With the Space Station as a base, we must 
place a permanent colony on the moon. 

• Then, we must explore Mars with people. 

The 1969 task force study also had some ambi- 
tious projections for the near future of American 
spaceflight: NASA planned to complete the 
Apollo program by 1972 with the Apollo 18 mis- 
sion, and Skylab A was to be completed by 1974. 

As Associate Administrator for Manned Space 
Flight, I had some projections of my own in 1970. 
Skylab B was also planned for early 1976, the 
first flight of the Space Shuttle in 1976, a large 
Space Station by 1980, and the beginning of con- 
struction on a lunar base by 1985. 

In the meantime, after 1967, the NASA budget 
started falling at about 14 percent per year. 
Manned Space Flight’s budget was cut in half 
from 1966 to 1971. Part of that decline was 
because Congress and the administration were 
beginning to have misgivings about the 
continued risk of lunar flights. So were some in 
NASA. By 1970, it was obvious that the decline 
would continue, and drastic action had to be 
taken in planning NASA’s future. 

First, all studies and technologies associated 
with Mars were stopped. We canceled Skylab B. 
Then Apollo 18 was canceled (under pressure 
from Congress). Finally, the lunar base and the 
large Space Station were deferred, with the final 
launch of Saturn V then pegged to Skylab A. 
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As budget pressures continued, we held discus- 
sions with European nations to consider their 
roles in space exploration. We discussed their 
providing parts for the Space Shuttle, the whole 
Space Tug and finally settled on Spacelab as an 
appropriate item for European interests. Many 
painful diplomatic discussions were held in that 
series of negotiations. Space Tug was dropped. 

The order of priority for the cutback was based 
on a conviction that if we could just reduce the 
cost of transportation to low Earth orbit dra- 
matically, the future would fall back in place. 

In 1970, we already had underway a Phase A 
study of the fully recoverable, two-stage Shuttle. 
Budget pressures from the administration were 
continuing, and although no numbers had been 
developed, it was evident that a program above 
$10 billion would not fly. Industry saw the prob- 
lem, too, and began to come up with partially re- 
coverable systems. In 1971, the administration 
began to talk about $5 billion for the develop- 
ment program, and it was clear that we now had 
to look very seriously at partially recoverable 
systems. Consequently, many new configura- 
tions were studied, leading to a number of possi- 
bilities, fully costed and ready for use in cost 
trade studies. 

At about the same time, and after a long debate 
with the Office of Management and Budget, 
NASA agreed to demonstrate the cost effective- 
ness of a reusable shuttle system. This decision 
bad an enormous impact on the design decisions 
for the program. 

We hired Mathematicians, with Dr. Klaus P. 
Heiss as the project leader, to run a total cost 
versus total savings study for a 20-year period. 
The key cost data for this study was the develop- 
ment costs, the cost per flight, the number of 
flights per year, and Shuttle effects on the cost of 
payloads. 

The Development Costs 

A two-stage, fully recoverable launch vehicle 
was our starting point. We looked at Max Hunt- 
er’s single stage to orbit model, but decided that 
the structure weight left us with no reserves. We 


recognized that with the Saturn V production 
line being closed down, the vehicle should have 
a large diameter payload bay to accommodate a 
future Space Station. We had an agreement 
with the administration that NASA would pay 
for development of the Shuttle, and that the Air 
Force could use it if they paid launch costs. 
When we made that offer to the Air Force, they 
agreed, but wanted a cross range capability to 
return to base during polar launches from Van- 
denburg AFB. We agreed, because it was becom- 
ing obvious that to meet the cost effectiveness 
criteria, we would need all the launches we 
could get. As noted above, European space inter- 
ests had agreed to build Spacelab, thereby add- 
ing reusable payloads. 

Cost Per Flight 

Launch costs were badly underestimated. Al- 
most all our emphasis was put into pushing 
down the development costs to get under the ad- 
ministration’s bogey. Although President Nixon 
was a space buff, I am convinced that he and 
OMB were in lockstep in demanding a less cost- 
ly Shuttle. Unfortunately, we relied too heavily 
on airline-supplied data on what this airplane- 
like device could cost per flight if we followed 
airline maintenance and on-line checkout rules. 
NASA’s lack of an operations voice at or near 
the top of the agency caused us to naively be- 
lieve (or hopefully believe?) that these very low 
costs per flight could be met. In retrospect, I 
have become convinced that some of the project- 
ed launch costs reductions could have been ob- 
tained, had the entire design team concentrated 
on operations as strongly as they concentrated 
on development. 

Number of Flights Per Year 

I believe our final cost effectiveness study was 
based on 50 or 60 flights per year. After all, we 
were going to have drastic reductions in cost per 
flight, particularly at high flight rates. With the 
airline industry’s advice that we could check the 
Shuttle out like a commercial transport, our pro- 
jections of manpower at the Cape were much 
smaller than for the Saturn program. We had a 
large projection of Air Force payloads, the prom- 
ise of European payloads in addition to Space 
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Spacelab, and a plan to build relatively cheap 
scientific payloads that could be modified be- 
tween flights and flown over and over. Finally, 
we expected to carry a large number of commer- 
cial payloads, most of which would be communi- 
cations satellites. 

The Cost of Payloads 

With the Shuttle’s capability to carry bulky, 
heavy payloads, the concept developed that we 
could build heavy, simple “I-beam” structures 
for a space bus system, load them with instru- 
ments, and fly them over and over, with a differ- 
ent, or upgraded instrument package. We could 
leave them in space, and then recover them, 
modify them, and redeliver them to space. With 
low costs per launch, and many launches, this 
projected reduction in payload cost contributed 
to the cost effectiveness of the system. 

The Results 

Even with these aggressively cost-effective 
numbers, the study results showed, that to be 
fully cost effective we had to go with one of the 
lowest development cost systems. OMB, I’m 
sure, expected that result, and Congress liked it 
because of other budget pressures. Whatever the 
outcome of the study, the administration had de- 
cided that NASA could have any kind of Shuttle 
it wanted, as long as the development costs were 
equal to or lower than $5.5 billion. In January 
1972, when the Shuttle go-ahead was given by 
President Nixon, Jim Fletcher got a handshake 
agreement for an additional 20 percent reserve 
over my 15 percent reserve (mine was included 
in the $5.5 billion). That 20 percent reserve, had 
we applied it to reducing operational costs, could 
have made a big difference. Unfortunately, the 
reserve was essentially removed by the adminis- 
tration when a leak occurred and the Wall 
Street Journal reported that the cost could run 
as high as $6.6 billion. 

Design Considerations 

While the cost effectiveness study was going on, 
some important trade studies continued 
throughout the Phase A, Phase B, and Phase 
B+ studies carried out by industry. Decisions 
were 


were made at the top level of NASA on items 
that affected the Program Authorization Docu- 
ment. These included the studies that led to a 
blended delta wing rather than a straight wing, 
the choice of parallel boosters rather than a se- 
ries booster, solid strap-ons rather than liquid, 
the payload bay size (length and width), payload 
weight, and cross range. 

A report written by Charles Donlan in 1972 (fol- 
lowing this article) summarized the wide rang- 
ing configuration studies done between 1970 
and the end of 1971. It is important to note that 
in many cases, decisions were made which re- 
duced the development cost at the expense of op- 
erating costs. The choice of solid boosters is a 
case in point. NASA had extensive experience 
with liquid boosters, but there was overwhelm- 
ing evidence that solids would be over a billion 
dollars less expensive to develop than liquids. 

There was also a 100 percent reliability record 
for large solids at that time. In the final review 
concerning choice of solids or liquids, we were 
presented evidence that we could cancel the sol- 
id motor thrust in flight, and even abort from 
them. Later, we found that we could not escape 
from the solids, but would be better off riding 
them out. But, at the time, we had concluded 
that we had very low development cost, very 
high reliability, an abort capability, and a 
means of reducing the cost per flight by recover- 
ing and reusing the solids. 

Postscript 

NASA did well in meeting the development cost 
set out for the program. They missed it by about 
5 to 10 percent in 1971 dollars. 

They missed badly on operational costs. First, 
the airline idea of designing with triple redun- 
dancy, but flying with a system out, was naively 
accepted at the time, but was never possible in 
manned flight. The risk, and the relatively un- 
developed systems, could not be compared to 
commercial aircraft’s 30 years of evolutionary 
development. Second, with NASA’s approach to 
checking all critical circuits and understanding 
the personality of all components used for our 
manned flights, there was no way we could 
come. 
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come close to the number of 50 to 60 flights per 
year used in the study (and flights per year is 
the dominant factor in cost per flight). 

A rough estimate of how well we did in 
operations costs can be reached by correcting 
our 1971 figures for the increase in cost per 
flight resulting from flying 12 per year rather 
than 50, and then comparing those costs to those 
corrected estimates from 1971 (in real dollars). 
We still missed our costs per flight by a factor of 
two or three. Lost over the years, however, was 
the fact that the original costs per flight were 
based on accounting only for the “additive 
costs,” over and above the personnel who would 
be in place if we did not have a Shuttle. 

There have been a few ruggedly designed pay- 
loads, but there was never a NASA directive to 
have any. There have been a few payloads recov- 
ered, and a few fixed in orbit, but the bookkeep- 
ing doesn’t show a reduction in transportation 
cost to give credit to the transportation system. 


All things considered, I judge the Shuttle to be a 
resounding success. It has done everything in 
space that we set out to do. Perhaps, considering 
the 1970 budget setting, there was no other way 
to get a program going than through the some- 
what ethereal cost effectiveness approach that 
was taken. 

The configuration of the Shuttle has been su- 
perb. To fly from Mach 25 to a perfect landing is 
a major step forward in aeronautics, but to do it 
with the configuration that was defined at the 
end of phase B is a tribute to the team of NASA 
and industry personnel who defined it. 

Finally, the Program Authorization Document 
system worked. That relatively limited set of re- 
quirements, approved by the Administrator or 
the Deputy, brought stability to the program. 
No change to those few top specifications could 
be made without convincing the Administrator 
of the need. That was priceless in holding down 
changes during the development program. 


Shuttle Comparison 




Flyback 



Liquid 




Rocket 

Motor 
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Space Shuttle Systems Definition Evolution 
by Charles J. Donlan 
Acting Director, Space Shuttle Program 
July 11,1972 

The initial studies, begun in 1969-70, addressed a fully reusable shuttle system which emphasized 
minimum refurbishment, autonomous on-board checkout, minimum turnaround time, and the low- 
est operational cost of any system studied. The operational cost, about $4 million per flight, is about 
the same as for the Thor Delta launch vehicle — the most widely used launch vehicle in the United 
States. The development costs of the fully reusable system, however, approach $10 billion and re- 
flect the extensive research and development activity associated with developing two large piloted 
vehicles that possess both the features of a rocket launch vehicle and a hypersonic aircraft. 

Further studies yielded a system with a smaller, more efficient orbiter by the use of expendable hy- 
drogen tanks, rather than propellant tanks located in the orbiter. The booster staging velocity was 
lowered from 11,000 feet per second for the fully reusable system to 7,000 feet per second. This al- 
lowed use of a heat sink booster so that the development costs were lowered to $8 billion. The ex- 
pendable tankage, of course, meant somewhat higher operational costs of $4 million per flight. The 
high risk and high peak annual funding associated with developing two piloted vehicles still existed 
and studies for lower cost systems continued. 

Eventually, by removing both the liquid oxygen and liquid hydrogen from within the orbiter, NASA 
was able to devise a much smaller, lower cost orbiter with a single expendable combined propellant 
tank. The size of the orbiter and its development costs were dramatically reduced while retaining 
equal performance capability by utilizing this expendable tank for both liquid propellants. The se- 
lected orbiter is a delta wing aircraft, powered by high pressure hydrogen-oxygen engines. 

Time phasing some of the orbiter subsystems received considerable study effort. This was known as 
the Mark I/Mark II shuttle system. The Mark I orbiter was to use available ablative thermal protec- 
tion, a J-2S engine developed as a extension of the existing Saturn J-2 engine, and other state-of- 
the-art components such as existing avionics. Improved subsystems such as fully reusable thermal 
protection and the new high pressure engine would be phased into later orbiters to achieve the oper- 
ational system (Mark II). This time-phasing reduced expenditures early in the development cycle, 
but the Mark I system had reduced payload and cross range capability as well as an increased turn- 
around time of one month. This represented a severe loss in operational capability. Furthermore, the 
total development costs to achieve the full Mark II system actually increased. 

Additional studies indicated that further reductions in orbiter development costs could only be 
achieved at the expense of compromising the objectives of providing the required flexible orbital ca- 
pability at low operational costs. The possibility was considered of reducing total systems costs 
through reducing the size of the payload bay in the orbiter from 4.6 X 18 meters (15 X 60 feet) to 4.3 
X 14 meters (14 X 45 feet) and reducing the payload capability for a due east launch from 29,500 
kilograms (65,000 pounds) to 20,400 kilograms (45,000 pounds). The additional cost savings were es- 
timated to be only about $70 million in the development program. Furthermore, the orbiter with the 
smaller payload compartment was unable to accommodate about 10 percent of the projected civil 
missions and about 37 percent of the projected military missions for a typical mission model for the 
period 1979 - 1990. Therefore, the smaller shuttle would have required retention of large expendable 
boosters in the U.S. launch vehicle inventory to handle the larger payloads, thus incurring higher 
costs than were achievable with the baseline shuttle system. 
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The Mark Mark II concept would have used Saturn F-l engines but nevertheless would have teen 
a costly and relatively high-risk undertaking since, again, I two manned ret urnable ve 

quired to be developed. Its development cost was estimated at between $6 and $7 bi 

^rflight of approximately $7 million. In a further attempt to reduce thedevelopmentcost, studies 
were initiated to examine a shuttle configuration utilizing an unmanned ballistic booster. 

Evolution to the Current Shuttle Configuration 

The introduction of the external tank orbiter had a major impact on the booster element of the shut- 
tle system. Since the orbiter became much more efficient, it became possible to let lt ta ^ ev ^ 
of the burden of propelling the shuttle into orbit. Staging could therefore occur at about 5,°°0 feet 
per second. An important advantage from the use of the external tank orbiter was the opportunity to 
Utilize ballistic liquid boosters or solid rocket motor boosters that are efficient at the lower stagi g 
velocities. Their use promised the greatest reduction in development costs. 

The ballistic unmanned booster studied included both pressure-fed and pump-fed liquid propellant 
boosters and solid propellant boosters. The two liquids compared as follows: 

In the pressure-fed system, the engine would have been a major new development. In the pump-fed 
system, it would have been a modified F-l engine (the engines used in the Saturn V booster). 

New manufacturing techniques would be required for the pressure-fed booster, conventional tech 
niques developed for Saturn would be used for the pump-fed. 

Major modification of facilities would be required for the pressure-fed booster; to a large extent, ex- 
isting facilities could be used for the pump-fed booster with minor modifications. 

The stiff thick walls of the pressure-fed booster could withstand a moderately high impact velocity, 
and thus’ it lent itself to booster recovery. Recovery of the thin-walled pump-fed booster appeared to 
be of much higher risk. 

It was concluded that the pump-fed system had cost advantages and lower technical risk in aU as- 
pects except the recovery risk, which appeared large. Of the two liquids, the pump-fed concept was 
deemed more advantageous in spite of the need to develop complex recovery systems. 

After we examined the liquid booster class, a comparison was then made against solid rocket motor 
configuration. Conventional expendable pump-fed systems currently exist in the series bu 
figuration where the orbiter engines are ignited after booster shutdown and separation However , a 
parallel bum configuration where both booster and orbiter engines are ignited at liftoff takes maxi- 
mum advantage of the high performance orbiter engines. This parallel burn con ^^ r ^^°” ^ P he 
ticularly attractive for the solids where it is desirable to stage at a low velocity and to minimize the 
size of solids for operational cost reasons. The pump-fed liquid booster in the series configuration 
was therefore compared with the parallel burn solid rocket motor booster. 

Due to the high cost for each pump-fed booster, recovery refurbishment and reusabiH^ 
tial while for the SRM this is not so critical. Essentially, the net cost of losing a liquid booster would 
be much greater than losing a solid, jeopardizing the ability of the shuttle to attain the low msts of 
recurrent operations. In addition, providing recovery would entail major developmental risks for the 
liquid but would be simpler for the solids. 
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Development costs of the solid booster are estimated to be about $700 million fewer than those of the 
liquid booster. Environmental effects for both liquid and solid systems were about the same with one 
exception— propellants and their exhaust products. The liquid booster would use RP, a kerosene-like 
rocket propellant, and liquid oxygen, and its exhaust products would be chiefly carbon monoxide, 
water vapor, and carbon dioxide, along with smaller quantities of hydrocarbons and ammonia. The 
chief emissions from the solid rocket motors are hydrogen chloride, carbon monoxide, water vapor, 
and aluminum oxide. 

It was finally determined that, of the unmanned ballistic boosters, the solid booster recoverable sys- 
tem with parallel orbiter burn would give the lowest development cost ($5.15 billion), least capital 
risk per flight, and lowest technical risk of development. In addition, economic studies have shown 
that this system will provide the highest rate of return on investment. Environmental effects would 
be minor, although it would be necessary to impose additional but acceptable constraints on 
launches associated with the likelihood of rain. 

Summary 

Preliminary design studies of the initial two-stage fully reusable concept showed that the size of the 
system and its development cost could be greatly reduced through the use of an external expendable 
liquid-hydrogen tank for the orbiter, with a small increase in operating costs per launch. Further 
study showed that additional cost savings and technical advantages in the development program 
would accrue if both the liquid-oxygen and liquid- hydrogen for the orbiter were carried in an exter- 
nal tank jettisoned from orbit. This change permitted the orbiter vehicle to be significantly smaller 
and more efficient, thereby simplifying the booster development and reducing substantially the de- 
velopment and procurement costs at the expense of some additional increase in the recurring cost 
per flight. Consideration of all factors led to the selection of the solid rocket motor booster, parallel 
burn system for the Space Shuttle. All configuration comparative issues have been studied in great 
detail both in and outside of NASA, to evolve this most cost-effective space transportation system. 
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Resources for NASA Managers 


by William M. Lawbaugh 


What’s New in the Library Collection 

Following is a list of books and articles that 
have most recently been added to the PPM 
Library Collection. All of the materials may be 
borrowed through interlibrary loan from you 
Center Library except the Summer Study 
documentation. (The sheer volume of paper 
makes this study difficult to circulate.) Call 
202/453-8740 or FTS 8-453-8740 for further 
information. 

Project Management Summer 1991 Study 
documentation, which includes 10 volumes of 
information plus individual papers and earlier 
NASA management studies. 

The Organizational Behavior Reader 
Edited by David A Kolb, Irwin M. Rubin, and 
Joyce S. Oslond 

5th ed. 1991. Call Number HF5548.8 .K552 
1991. 

Thinking About Management 

by Theodore Levitt, 1991. 

Call Number: HD31 .L3848 1991. 

Quality Training: What Top Companies 
Have Learned 
by Kathryn L. Try 

The Conference Board Report Number 959, 
1991. Call Number: HF5549.5 .T76 1991. 


NASA, Maintaining the Program Balance, 
National Academy of Public Administration, 
1991. Call Number: TL521.312 .N374 

A Report by the Academy Panel examining the 
distribution of NASA science and engineering 
work between NASA and contractors and the 
effect on NASA’s in-house technical capability. 


Business Ethics: Ethical Decision Making 

and Cases 

by O.C. Ferrell, 1991. 

Call Number: HF5387 .F47 1991. 

CASE: Computer-Aided Software 

Engineering 

by T.G. Lewis, 1991. 

Call Number: QA76.758 .L49 1991. 

Project Management: How to Plan and 
Manage Successful Projects 
by Joan Knutson, American Management Asso- 
ciation, 1991. 

Call Number: T56.8 .K58 1991. 

System Engineering Management 
by Benjamin S. Blanchard, 1991. 

A Wiley-Interscience Publication series entitled 
New Dimensions in Engineering. Call Number: 
TA168.B531991. 

A Review of the Office of Aeronautics and 
Space Technology’s Management Processes 
and Practices 

by the National Academy of Public Administra- 
tion, 1991. 

Call Number: TL521. 312 .R48 1988. 

NASA Project Status Reports: 
Congressional Requirements Can be Met, 
but Reliability Must be Insured 
General Accounting Office, GAO/NSIAD-90-40, 
1990. Call Number: T58. 4 .U55 1990. 

Articles 

Risk Management Integration with System 
Engineering and Program Management, 
by G. Vlay, presented at AIAA Space Programs 
and Technologies Conference September 25-28, 
1990. Call Number 91A10139. 
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The Causes of Project Failure 
by Jeffrey K. Pinto and Samuel J. Mantel, Jr. in 
IEEE Transactions on Engineering Manage- 
ment, Vol. 37, No. 4, November 1990, pp. 269- 
276. 

Call Number: 91A19889. 


Can Space Exploration Survive the End of 
the Cold War? 

by Bruce Murray, Space Policy Vol. 7, No. 1, 
February 1991, pp. 23-34. 

Call Number 91A27566. 

Risk Assessment and Program 
Management 

Jerold Haber, in Aerospace Testing Seminar 
March 13-15, 1990, Proceedings of the Institute 
of Environmental Sciences, pp. 31-38. 

Call Number: 91A29698. 

Concurrent Engineering: The Challenge for 
the 90s 

by Kevin M. Smith and Carol A. Marlin, pre- 
sented at National Aerospace and Electronics 
Conference, May 21-25, 1990, pp. 1313-1323. 

Call Number: 91 A3 1023. 

The Explorer Platform Planning System: 
An Application of a Resource Reasoning 
Planning Shell 

by David R. McLean, Brenda J. Page and Wil- 
liam J. Potter, in Proceedings of the ESA Sym- 
posium June 26-29, 1990, ESA SP-308, October 
1990. Call Number 91N22222. 


Mars: A Generic Mission Planning Tool 
by A. Killner, N. Schielow, F. Zapp, in Proceed- 
ings of the ESA Symposium June 26-29, 1990, 
ESA SP-308, October 1990. 

Call Number 91N22238. 

Manager's Handbook for Software 

Development Revision 1 

November 1990, Goddard Space Flight Center, 

Software Engineering Laboratory Series, SEL- 

84-101. 

Call Number 91N15773. 


Book Reviews 


Government-Industry Project 
Management Terminology and 
Documentation Manual 
(HD 69 .P75 G68 1991) 

This 130-page manual is compiled by an Air 
Force support contractor in order to serve as a 
course training tool and to propose standard ter- 
minology for the project office, contractor, sub- 
contractor and user. Presumably, when they all 
speak the same language and mean the same 
things, teamwork will result. 

The loose-leaf Terminology and Documentation 
Manual begins with a rather odd “List of Acro- 
nyms and Abbreviations” with only one abbre- 
viation: “Synth.” for Synthesizer. Some you will 
find nowhere else (such as “WAG” for “wild ana- 
tomical guess”), while more standard acronyms, 
such as WAD for Work Authorization Docu- 
ment, or WAN for Wide Area Network, are 
missing. 

Section 2 is a 60-page “Definition of Terms,” 
again somewhat arbitrary and incomplete. Defi- 
nitions range from the obvious (“Teamwork. 
Working together to achieve a common goal.”) to 
the oblique (“Tiger Team. Focused visibility, 
evaluation and recommendations by objective 
specialists relative to an identified area of con- 
cern.”). In its “System Hierarchical Structure,” 
a “part” is ranked as lowest and “system” as 
highest, above “element” and “segment.” 

Section 3 is “Control State Descriptions,” begin- 
ning with Source Selection Initiation Review 
(SSIR) and ending with Operational Readiness 
Review (ORR). This is perhaps the most valu- 
able part of the manual because of its Q/A for- 
mat and detail. Section 4, “System Documenta- 
tion: Content and Outlines,” however, is least 
helpful because of its sketchiness. Section 5, 
“Symbols,” is a mere couple of pages on arbi- 
trary symbols and a master schedule. 

This manual, despite its shortcomings, is a start 
towards a reliable, consistent and comprehen- 
sive glossary for project management. A better 
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one may be the PPMI Lexicon by Dennis E. 
Fielder, available through the PPM Library col- 
lection. 

Defense Acquisition Management Policies 
and Procedures 

(DoD Instruction 5000.2: February 23, 1991) 

In the past. Department of Defense acquisition 
management policies and procedures were pub- 
lished in dozens of separate directives and 
instructions. While they were all cross- 
referenced, they “defied practical use” by man- 
agers and contractors alike. This instruction 
consolidates 45 such documents into about 500 
pages for the program manager, milestone deci- 
sion authorities and their staffs along functional 
and organizational lines. 

Besides general acquisition policies and proce- 
dures, DoD Instruction 5000.2 covers require- 
ments planning, risk management, systems en- 
gineering, configuration and data management, 
contracts, program control and test and evalua- 
tion activities in support of the acquisition pro- 
cess. 

Acquisition in the DoD has been an issue of keen 
interest in the past decade. Understandably, 
part of the problem has been the maze of laws, 
directives and instructions that go in and out of 
effect. The instruction would go a long way to- 
wards fair, consistent and coordinated acquisi- 
tion in defense programs were it not for its 
dense, abstract writing. 

Systems Engineering Handbook. 2 Volumes 
(Systems Analysis Division: Marshall Space 
Flight Center, 1991) 

Faced with the impending retirement of many 
experienced engineers, MSFC saw the need “to 
capture their knowledge and make it available 
to the next generation of systems engineers.” 
The result is two well written, well organized 
volumes, nicknamed “roadmap” and “toolbox.” 

Volume I, completed in February 1991, is 117 
pages entitled “Overview and Processes,” show- 
ing “how MSFC does it.” After a brief overview 
of the NASA phased project planning process 


(phases A to D), Volume I covers the entire sys- 
tems engineering process from planning and 
definition to post-mission evaluation. Tying it 
all together in an elaborate process flow chart, 
the “roadmap,” which is reduced and highlight- 
ed in each section to show how the topic fits in 
the larger scheme of systems engineering. 

The “toolbox” of Volume II was completed in 
May 1990 and is twice as thick. This volume 
consists of documentation, applicable specifica- 
tions and standards, analyses and checklist, pro- 
cesses and checklist, and summary of systems 
engineering tools and models, and a fascinating 
list of lessons learned from past programs. Each 
area is replete with templates and fact sheets 
which explain the tools, techniques, analyses 
and documentation formats. This volume is not 
as tightly organized as Volume I, but contains 
useful, valuable information. 

While the text is readable and the figures are 
clear, some of the schematics in Volume II are 
overly complicated and the Volume I introduc- 
tion refers wrongly to the “roadmap” as Figure 
12 (not 11). Nevertheless, MSFC’s Systems En- 
gineering Handbook is a good start in an in- 
creasingly important and detailed discipline. 

The Space Station Decision: Incremental 
Politics and Technical Choice 
by Howard E. McCurdy 

(Baltimore: Johns Hopkins University Press, 
1990) 

Under contract with NASA, American Universi- 
ty public affairs professor Howard E. McCurdy 
has produced the second in the New Series in 
NASA History. (Henry Cooper’s Before Lift-off 
about Shuttle astronauts was first in the series.) 
It comes right on the heels of Levine and Naray- 
anan’s Keeping the Dream Alive, which covers 
much the same time period. Both accounts rely 
heavily on the NASA History Office and its then 
director, Dr. Sylvia Fries (spelled “Fires” in 
McCurdy’s acknowledgements) as well as inter- 
views with some of the Space Station Task Force 
members. 

McCurdy’s study, by far the most extensive to 
date, focuses on that “one brief shining moment” 
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in NASA between Apollo and the present which 
has captured the imagination of aerospace writ- 
ers and researchers. The 1984 decision to build 
the space station says so much about NASA’s 
past and future, but so far none of the original 
task force members has attempted to tell “the 
inside story.” That story, not fully told in official 
documents, has been patched together with in- 
terviews, usually pointing to a particular theory 
or thesis. 

Professor McCurdy’s thesis is implied in the sub- 
title: “Incremental Politics and Technological 
Choice,” with the further implication that the 
former affects or even shapes the latter. The the- 
sis is simple: The Apollo decade had focus, pur- 
pose and commitment; during the next two dec- 
ades, the civil space program “settled into the 
swamp of incremental politics.” There was no vi- 
sion, no goal. 

Technological choice is another matter. NASA 
came up with a way to get Americans to the 
moon just 14 months after President Kennedy 
approved the program. President Nixon got a 
Shuttle configuration in March 1972, within 
three months of approval. But for space station, 
“NASA slogged through a series of designs.” Re- 
member the power tower, dual keel, single 
boom, revised baseline and rephasing? 

What happened this go-around? McCurdy points 
to two inherent problems which suggest decep- 
tion. First was cost. The original $8 billion cost 
estimate was not at all realistic. Not even a 
stripped-down station could be launched for 
that. Secondly, the original space station prom- 
ised too much to too many. Defense may have 
wanted an observation post but the Europeans 
did not want military presence; life scientists 
people wanted a large, active crew, but materi- 
als scientists needed microgravity and Mars- 
mission people preferred a service station for re- 
fueling. The reader is left wondering whether 
the present-day problems with funding and con- 
figuration are a result of raw, deceptive politics 
or bad technological choices made in the past. 
Perhaps either or both would be gross oversim- 
plification, as a strong case could be made for 
other debilitating factors such as history (espe- 
cially the impact of the Challenger disaster), 


management (personnel and methodology), age 
distribution (the natural aging of Apollo-era em- 
ployees), not to mention public relations or the 
1981 tax cut. 

Elsewhere, for example, McCurdy has argued 
that Apollo-era NASA was “hands-on” techno- 
logically competent, but later became noted for 
its contracting out. (See Space Policy, November 
1989, for example.) Such a theory would either 
enhance or disprove his thesis in The Space Sta- 
tion Decision, but it would more than likely alter 
the book’s subtitle. Perhaps the problem is what 
appears to be long gap between research and 
writing. The book came out in late 1990, but 
most of the firsthand interviews took place in 
1985 and 1986. 

Nevertheless, the decision to build Space Sta- 
tion Freedom is fraught with intense interest, 
scrutiny and even mystery. Additional studies of 
this 1984 decision are forthcoming, and each one 
will understandably add another perspective, 
other insights. For now, though, McCurdy’s 
book is the book on the subject; for how long de- 
pends on insiders or Task Force members who 
take up the pen. 

Project Management Tools for Engineering 
and Management Professionals 
by Adediji B. Badiru 

(Norcross, GA: Industrial Engineering and 

Management Press, Institute of Industrial Engi- 
neers, 1991) 

This assistant professor of industrial engineer- 
ing at University of Oklahoma describes his 
book as “a collection of project management 
tools ... for the engineering and management 
professional.” It presumes prior knowledge and 
previous study of most of these “tools” for none is 
described or explained in any detail. MBO, for 
example, is given two thin paragraphs; so is 
Maslow’s Hierarchy of Needs; McGregor’s The- 
ory X and Theory Y gets three paragraphs; TQM 
four. However, an awful lot of “tools” are men- 
tioned in the 428 pages of text and appendices, 
and in about 150 figures and tables. The tools re- 
ceiving the most attention are WBS, CPM, 
PERT, Gantt charts and MARR (minimum at- 
tractive rate of return) methods. 
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If Badiru has a theme or point of view in his 
compilation, it would be this; w In the real world, 
there are no right answers. There are only op- 
tions. He explains that new engineers quickly 
find that the theoretical and quantitative tech- 
niques of project management learned in school 
do not necessarily apply in the “real” world. 
More often than not, the practical mana-ger 
must settle for a “near-optimal” alternative in 
lieu of a perfect solution. H.A. Simm discovered 
this reality nearly 40 years ago and dubbed it 
satisficing. Badiru applies the concept to pro- 
ject management decision making. 

The author is strong on the economic aspects 
and quantitative analysis of project manage- 
ment, but his most original approach is the area 
of software tools for project managers. He 
evaluates 19 software programs, from Microsoft 
Project to Control Project, most of which can run 
on personal computers. However, this rather 
unique effort may also date the book quickly as 
new software for project management comes on 
the market and old programs are updated and 
improved. Even in the time it took to finish the 
book, prices changed dramatically. Artemis 
Project, for example, is listed at $5,000 for a 
single copy in the text but at $3,500 in the 
Appendix. Likewise, Harvard Project Manager 
software is listed at $695 in the text but a 
hundred dollars less 50 pages later. To 
compensate, another handy appendix supplies 
addresses and telephone number for major 
software developers in the field of project 
management. 

Beyond the Myths and Magic of Mentoring: 
How to Facilitate an Effective Mentoring 
Program 

by Margo Murry, with Mama A. Owen 
(San Francisco: Jessey-Bass Publishers, 1991) 

A lot of people are talking about “mentoring” 
these days, yet little is written about it, even 
though it is an ancient concept. It dates back at 
least to Homer, who chronicles the appointment 
of Mentor who looks after Telemachus for a 
decade until the boy’s father, Odysseus, returns 
from the siege of Troy. Today it is perhaps the 
latest buzzword in management circles. 


Yet, as the authors of this book note, mentoring 
“has been applauded as the best and criticized as 
the worst thing that can happen in one’s career.” 
They state flatly, “some organizations and some 
people will never be ready for mentoring.” 

The authors are president and senior associate 
of a firm called “MMHA-The Managers’ Men- 
tors, Inc.,” although the acronym is not spelled 
out. In trying to explain mentoring, they say it 
has nothing to do with role models, “distant 
stars” or sponsors. Rather, they call it “facilitat- 
ed mentoring” which involves a mentor and a 
protege in a formal but willing relationship of 
sharing skills or experience, systematically. 

Perhaps the clearest example of a successful 
mentoring program cited is at Trinity College in 
Washington, D.C. Here, undergraduate 
students are paired with alumnae in the same 
professional field who together negotiate a set of 
activities they will share over the semester. 
Companies and government agencies are also 
cited as having formal or informal mentoring 
program. The IRS mentoring program in 
Kansas City, for example, encourages 
professional and personal growth. 

To make mentoring work, the authors suggest a 
pilot program first, then plenty of planning, 
training, coordination and evaluation. They are 
not blind to gender and culture issues in the 
workplace, such as sexism and racism. Unions 
are seen as more of a help than a hindrance in 
the mentoring process, providing grievance pro- 
cedures and due process when problems arise. 
They also recognize the Yankee streaks of inde- 
pendence in American business: “We do not 
have the patience of the Japanese nor the true 
team spirit of the Scandinavians . . . Meanwhile, 
divorce statistics in the United States prove that 
we are becoming worse at managing relation- 
ships. The key, the authors say, is “persistence” 
to bring about the benefits of facilitated mentor- 
ing. 

So far, facilitated mentoring” seems to work 
best in schools and charitable organizations 
where supports systems are already in place to 
compensate for the greed, sabotage and selfish- 
ness often attributed to people climbing the lad- 
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der in corporate America. Whether mentoring 
takes hold in government or industry may de- 
pend upon whether the concept is presented in 
trendy workshops or in serious studies. This 
book is a modest start. 

Engines and Innovation: Lewis Laboratory 
and American Propulsion Technology 
by Virginia P. Dawson 
(Washington: NASA SP-4306, 1991) 

In 1982 it looked like the beginning of the end 
for Lewis Research Center (LeRC). Staffing was 
down from 4,200 in 1971 to just 2,690 in ten 
years. The 1983 aeronautics budget had been 
halved by the Reagan budget trimmers. The 
then-influential Heritage Foundation marked 
Lewis for extinction in their blueprint, Agenda 
for Progress, by recommending the abolition of 
all of NASA’s civil aeronautics programs. The 
city of Cleveland had recently declared bank- 
ruptcy. And the newly appointed Center Direc- 
tor resigned. 

Within five years, Lewis phased out its famed 
energy research and was no longer a basic re- 
search laboratory where most of the work was 
done in-house. But it was still alive. In fact, em- 
ployment picked up considerably at Lewis with 
several new programs, including the Shuttle- 
Centaur program and the space power system 
work package for the Space Station Freedom 
Program. In the words of division chief William 
“Red” Robbins, “It was a damn miracle!” 

Although Engines and Innovation is part of the 
NASA History Series, author-historian Virginia 
Dawson modestly disclaims this is neither an 
administrative history of LeRC nor a chronicle 
of its achievements.” Rather, she says, “I hope 
that my book is a contribution to the current ef- 
fort among historians of technology to under- 
stand technological innovation as a social activ- 
ity or process.” In that, she succeeds admirably 
in a well-written book which captures the es- 
sence of technology transfer in the NACA and 
NASA eras. For example, she notes that Case 
Institute of Technology was on the receiving end 
of LeRC’s expertise in gas turbine and rocket 
technology until it developed graduate pro- 
grams and the situation reversed. 


Dawson thematically traces the rise and fall and 
rise again of Lewis Research Center from its cre- 
ation in 1941 as the NACA Aircraft Engine Re- 
search Laboratory (AERL) by NACA Director 
(from 1924-1947) George Lewis. By the end of 
the war it became known as the Flight Propul- 
sion Research Laboratory to reflect jet propul- 
sion and rocket research. NASA was formed in 
1958 and the lab took on its present name as it 
began crucial research in nuclear rocket sys- 
tems at the old Plum Brook Station 50 miles 
west. 

Dawson, a Ph.D. in the history of science and 
technology from Case Western Reserve, began 
work on this project in 1984 under contract to 
the NASA History Office, virtually from 
scratch. Only one book had been published on 
the topic, and that covered only liquid hydrogen 
propulsion at LeRC from 1945 to 1959. An un- 
published M.A. thesis helped with the war 
years, along with personal interviews with such 
LeRC legends as Abe Silverstein, Ben and Ir- 
ving Pinkel, and Bruce Lundin. However, the 
fascinating story, published in 1991, virtually 
ends in 1984; neither Andrew Stofan nor John 
Klineberg was even interviewed. She concludes 
that the challenge for LeRC is to restore “a bal- 
ance between research and development.’ 

To Engineer is Human: The Role of Failure 
in Successful Design 
by Henry Petroski 

(New York: St. Martin’s Press, 1985) 

“To understand what engineering is and what 
engineers do is to understand how failures can 
happen and how they can contribute more than 
success to advance technology. Thus, Henry Pe- 
troski, an engineering professor at Duke Uni- 
versity, begins his now-classic study of the hu- 
man side of engineering. 

You do not need to be an engineer to under- 
stand, appreciate and enjoy this slim, illustrated 
book of 250 pages. He begins with a clear ac- 
count of the 1981 collapse of the Kansas City 
Hyatt Regency Hotel skywalks and ends with 
his telling search of a famous Santayana quota- 
tion: “Those who cannot remember the past are 
condemned to repeat it.” 
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Much of the early part of the book is taken up 
with fairy tales (Goldilocks, the Three Litt e 
Pigs) and poetry (Oliver Wendell Holmes’ “The 
Deacon’s Masterpiece,” about “the wonderful 
one-hoss shay, that was built in such a logical 
way”) to illustrate his point that “success is fore- 
seeing failure.” No engineer wants to learn by 
mistakes, says Petroski, but there is not enough 
to learn from successes to go beyond the state-of- 
the-art. 

The hero-engineers are the Roebling brothers 
(Brooklyn Bridge) and Joseph Paxton, who built 
the Crystal Palace in Hyde Park. They were 
engineers who had vision and creativity. His 
bridge stories are most memorable, especially 
the undulating Tacoma Narrows Bridge. 

In the final chapters, however, Petroski reveals 
himself as a stick-in-the-mud, an incurable 
romantic. His narrative “from slide rule to 
computer” suggests that the latter, can be 
attributed to “computer-aided disasters” such as 
the roof collapse of the Hartford Civic Center, 
while the former forces an engineer to rely upon 
common sense and conventional wisdom in 
design. Nevertheless, as Petroski admits, it 
would be impossible to design or build a 
megaproject, like a nuclear power plant, without 
computer technology. 


One event that makes To Engineer Is Humana 
classic is the fact that a 50-minute film was sub- 
sequently made by Films Incorporated, bearing 
same title, starring the author. In the film ver- 
sion, Petroski begins with the Challenger disas- 
ter and ends with a successful night time launch 
of the Shuttle. Again, the focus is upon bridges, 
but his humanistic ideas are illustrated nicely 
with shots of pyramids and cathedrals. The PBb- 
quality film and book are complementary in 
showing failure and fatigue as useful design 
concepts. 

Computer Applications for Project Manage- 
ment: An Overview 

by Robert Mead, (Huntsville, AL: Camber 
Corporation, February 1991) 

This brief, 50-page outline of computer applica- 
tions is a resource for a project manager who 
seeks information on some very basic compu er 
applications. It is not for the expert. No one 
needs to be convinced that “computer systems 
can help the project manager/planner by doing 
some project management functions better, fas- 
ter, more accurately.” Choosing the systems is 
the main thrust of this presentation, but, as the 
author observes, ‘This is an area of dynamic 
change.” Better to seek out advice from periodi- 
cals, professionals, user groups and consultants. 




